文档帮助

术语、图标和标签

许多类在使用配置对象创建(实例化)类时都有快捷名称。快捷名称被称为 别名(如果类扩展了 Ext.Component,则为 xtype)。别名/xtype 列在适用类的类名旁边,以便快速参考。

访问级别

框架类或其成员可以指定为 privateprotected。否则,类/成员为 publicPublicprotectedprivate 是访问描述符,用于传达类或类成员应如何以及何时使用。

成员类型

成员语法

下面是一个类成员示例,我们可以对其进行剖析,以显示类成员的语法(在本例中,从 Ext.button.Button 类查看的 lookupComponent 方法)。

lookupComponent ( item ) : Ext.Component
受保护的

当原始配置对象添加到此容器时调用,无论是在 items 配置的初始化期间,还是在添加新项目时 added), or {@link #insert inserted

此方法将传递的对象转换为实例化的子组件。

当需要对子创建应用特殊处理时,可以在子类中覆盖此方法。

参数

item :  Object

正在添加的配置对象。

返回
Ext.Component

要添加的组件。

让我们看一下成员行的每个部分

成员标志

API 文档使用许多标志来进一步传达类成员的功能和意图。标签可以用文本标签、缩写或图标表示。

类图标

- 表示框架类

- Singleton 框架类。 *有关更多信息,请参阅 singleton 标志

- 组件类型框架类(Ext JS 框架中扩展 Ext.Component 的任何类)

- 表示类、成员或指南在当前查看的版本中是新的

成员图标

- 表示类型为 config 的类成员

- 表示类型为 property 的类成员

- 表示类型为 method 的类成员

- 表示类型为 event 的类成员

- 表示类型为 theme variable 的类成员

- 表示类型为 theme mixin 的类成员

- 表示类、成员或指南在当前查看的版本中是新的

类成员快速导航菜单

在 API 文档页面上的类名称正下方是一行按钮,对应于当前类拥有的成员类型。每个按钮显示按类型划分的成员计数(此计数在应用过滤器时会更新)。单击该按钮会将您导航到该成员部分。将鼠标悬停在成员类型按钮上将显示该类型的所有成员的弹出菜单,以便快速导航。

Getter 和 Setter 方法

与类配置选项相关的 Getter 和 setter 方法将显示在 methods 部分以及 API 文档和成员类型菜单的 configs 部分,就在它们工作的配置下方。 getter 和 setter 方法文档将在 config 行中找到,以便于参考。

历史记录栏

您的页面历史记录保存在本地存储中,并显示在顶部标题栏正下方(使用可用的实际空间)。默认情况下,显示的唯一搜索结果是与您当前查看的产品/版本匹配的页面。您可以通过单击历史记录栏右侧的 按钮并选择“全部”单选按钮来展开显示的内容。这将显示历史记录栏中所有产品/版本的所有最近页面。

在历史记录配置菜单中,您还将看到最近页面访问的列表。结果按“当前产品/版本”和“全部”单选按钮过滤。单击 按钮将清除历史记录栏以及本地存储中保存的历史记录。

如果在历史记录配置菜单中选择“全部”,则将启用“在历史记录栏中显示产品详细信息”复选框选项。选中后,每个历史页面的产品/版本将与历史记录栏中的页面名称一起显示。将光标悬停在历史记录栏中的页面名称上也会显示产品/版本作为工具提示。

搜索和过滤器

可以使用页面顶部的搜索字段搜索 API 文档和指南。

在 API 文档页面上,还有一个过滤器输入字段,该字段使用过滤器字符串过滤成员行。除了按字符串过滤外,您还可以按访问级别、继承和只读过滤类成员。这是通过使用页面顶部的复选框完成的。

API 类导航树底部的复选框过滤类列表以包含或排除私有类。

单击空的搜索字段将显示您最近 10 次搜索,以便快速导航。

API 文档类元数据

每个 API 文档页面(JavaScript 原始类型页面除外)都有一个与该类相关的元数据菜单视图。此元数据视图将具有以下一个或多个

展开和折叠示例和类成员

可运行的示例 (Fiddles) 默认在页面上展开。您可以使用代码块左上角的箭头单独折叠和展开示例代码块。您还可以使用页面右上角的切换按钮切换所有示例的折叠状态。切换所有状态将在页面加载之间记住。

类成员默认在页面上折叠。您可以使用成员行左侧的箭头图标或全局使用右上角的展开/折叠全部切换按钮来展开和折叠成员。

桌面与移动视图

在较窄的屏幕或浏览器上查看文档将导致针对较小外形尺寸优化的视图。桌面视图和“移动”视图之间的主要区别在于

查看类源代码

可以通过单击 API 文档页面顶部的类名称来查看类源代码。可以通过单击成员行右侧的“查看源代码”链接来查看类成员的源代码。

Sencha Touch 2.4


顶部

使用 MVC 管理依赖关系

在 Sencha Touch 应用程序中,可以在两个主要位置定义依赖关系 - 应用程序本身或应用程序类内部。本指南提供了一些关于如何在应用程序中声明依赖关系以及在何处声明依赖关系的建议。

应用程序依赖关系

当您创建 MVC 应用程序时,您的 Ext.application 为您提供了一种方便的方式来指定应用程序使用的模型、视图、控制器、存储和配置文件。这是一个例子

Ext.application({
    name: 'MyApp',

    views: ['Login'],
    models: ['User'],
    controllers: ['Users'],
    stores: ['Products'],
    profiles: ['Phone', 'Tablet']
});

这五个配置选项是加载应用程序通常包含的文件类型(模型、视图、控制器、存储和配置文件)的便捷方法。指定这些配置意味着您的应用程序将自动加载以下文件

  • app/view/Login.js
  • app/model/User.js
  • app/controller/Users.js
  • app/store/Products.js
  • app/profile/Phone.js
  • app/profile/Tablet.js

就加载的实体而言,上面的示例等效于手动定义如下依赖关系

Ext.require([
    'MyApp.view.Login',
    'MyApp.model.User',
    'MyApp.controller.Users',
    'MyApp.store.Products',
    'MyApp.profile.Phone',
    'MyApp.profile.Tablet'
]);

当您向应用程序添加更多类时,这些配置变得越来越有用,可以帮助您避免为每个文件键入完整的类名。但是,请注意,这些配置中的三个配置不仅仅加载文件,它们还执行以下操作

  • profiles - 实例化每个 Profile 并确定它是否应该 active。如果是,则还会加载 Profile 自己的依赖项。
  • controllers - 加载后实例化每个 Controller。
  • stores - 实例化每个 Store,如果未指定,则为其提供默认的 store ID。

这意味着如果您想利用 MVC 提供的所有便利,
在定义应用程序依赖关系时使用这些配置选项。

特定于配置文件的依赖关系

当使用 设备配置文件 时,您很可能有一些类仅在某些设备上使用。例如,您的应用程序的平板电脑版本可能比手机版本包含更多功能,这通常意味着它需要加载更多类。可以在每个 Profile 中指定其他依赖项

Ext.define('MyApp.profile.Tablet', {
    extend: 'Ext.app.Profile',

    config: {
        views: ['SpecialView'],
        controllers: ['Main'],
        models: ['MyApp.model.SuperUser']
    },

    isActive: function() {
        return Ext.os.is.Tablet;
    }
});

无论 Profile 是否处于活动状态,都会加载每个 Profile 中指定的依赖项。区别在于,即使加载了它们,Application 也不会知道如何进行额外的处理,例如在配置文件未处于活动状态时实例化特定于配置文件的控制器。

这听起来可能违反直觉 - 为什么要下载不会使用的类?我们这样做是为了生成可以部署到任何设备的通用生产版本,检测它应该使用哪个配置文件,然后启动应用程序。另一种方法是为每个配置文件创建自定义版本,创建一个微型加载程序,它可以检测设备应该激活哪个配置文件,然后下载该配置文件的代码。

虽然通用版本方法意味着您在每个设备上都在下载不需要的代码,但对于绝大多数应用程序来说,这只增加了很少的额外大小。

嵌套依赖关系

对于较大的应用程序,通常将模型、视图和控制器拆分为子文件夹,以保持项目井井有条。视图尤其如此 - 因为大型应用程序拥有超过一百个单独的视图类并不少见,将它们组织到文件夹中可以使维护更加简单。

要在子文件夹中指定依赖项,请使用句点 (".") 来指定文件夹

Ext.application({
    name: 'MyApp',

    controllers: ['Users', 'nested.MyController'],
    views: ['products.Show', 'products.Edit', 'user.Login']
});

在这种情况下,加载以下五个文件

  • app/controller/Users.js
  • app/controller/nested/MyController.js
  • app/view/products/Show.js
  • app/view/products/Edit.js
  • app/view/user/Login.js

注意 我们可以在此处的每个配置中混合和匹配 - 对于每个模型、视图、控制器、配置文件或存储,您可以指定类名的最后一部分(如果您遵循目录约定),也可以指定完整的类名。

外部依赖关系

我们可以通过完全限定我们要加载的类,从应用程序外部指定应用程序依赖关系。这种情况的一个常见用例是在多个应用程序之间共享身份验证逻辑。也许您有多个应用程序通过公共用户数据库登录,并且您想在它们之间共享该代码。一种简单的方法是在您的应用程序文件夹旁边创建一个文件夹,然后将其内容添加为应用程序的依赖项。

例如,假设我们的共享登录代码包含登录控制器、用户模型和登录表单视图,我们想在我们的应用程序中使用所有这些

Ext.Loader.setPath({
    'Auth': 'Auth'
});

Ext.application({
    views: ['Auth.view.LoginForm', 'Welcome'],
    controllers: ['Auth.controller.Sessions', 'Main'],
    models: ['Auth.model.User']
});

这将加载以下文件

  • Auth/view/LoginForm.js
  • Auth/controller/Sessions.js
  • Auth/model/User.js
  • app/view/Welcome.js
  • app/controller/Main.js

前三个文件从我们的应用程序外部加载,最后两个文件从应用程序本身加载。

注释

  • 您可以混合和匹配应用程序文件和外部依赖项文件。
  • 要加载外部依赖项,请使用 Ext.Loader.setPath 调用告诉 Loader 在哪里找到这些文件。

在此示例中,Loader 在我们的“Auth”文件夹中找到以“Auth”命名空间开头的类。我们可以将我们的通用 Auth 代码放入应用程序中 app 文件夹旁边,框架会找出如何加载所有内容。

每个依赖项所属的位置

在决定在何处声明每个依赖项时,一般规则是保持您的类完全自包含。例如,如果您的视图包含多个其他视图,则应在视图类内部而不是应用程序中声明这些依赖项

Ext.define('MyApp.view.Main', {
    extend: 'Ext.Container',

    requires: [
        'MyApp.view.Navigation',
        'MyApp.view.MainList'
    ],

    config: {
        items: [
            {
                xtype: 'navigation'
            },
            {
                xtype: 'mainlist'
            }
        ]
    }
});

然后,您可以在 app.js 中使用以下代码

Ext.application({
    views: ['Main']
});

这是声明这些依赖项的最佳方法,原因有两个 - 它使您的 app.js 保持整洁,并使您能够可靠地要求 MyApp.view.Main,同时知道它已经满足了所有依赖项。另一种方法是将所有视图都列在 app.js 中,如下例所示

//this is bad
Ext.application({
    views: ['Main', 'Navigation', 'MainList']
});

一种简单的思考方式是 app.js 仅包含顶级视图。如果您在应用程序中使用 Ext.create('MyApp.view.SomeView'),则该视图可以被认为是顶级的。每当视图仅作为另一个视图的子视图构建时(如上面的 MyApp.view.Navigation 和 MyApp.view.MainList),它都不属于 app.js。

自 Sencha Touch 1.x 以来的更改

在 Sencha Touch 1.x 中,依赖项通常在 Controllers 以及 Ext.application 调用中指定。虽然这种方法提供了一些便利,但也掩盖了系统的真实架构,并将视图、模型和存储与控制器过于紧密地耦合在一起。以下示例显示了 1.x 中可能存在的代码

//1.x code, deprecated
Ext.regController('SomeController', {
    views: ['Login'],
    models: ['User'],
    stores: ['Products']
});

这与在 Ext.application 中定义视图、模型和存储相同,但也提供了一些方便的方法来访问控制器内部的那些类。 1.x 生成了两个函数 - getLoginView()getUserModel() - 并公开了一个 getStore() 函数,该函数返回对在此 Controller 中定义的任何 Store 的引用。在 Sencha Touch 中,这些函数不再存在,但很容易使用替代方法。

在以下示例中,第一行指的是 Sencha Touch 1.x 代码,而第二行显示了 2.x 的方式

//creating a view - 2.x uses the standardized Ext.create
this.getLoginView().create();
Ext.create('MyApp.view.Login');

//getting a Model - just type out the Model name (it's shorter and faster)
this.getUserModel();
MyApp.model.User;

//Ext.getStore can access any Store whereas the old this.getStore only
//accessed those Stores listed in your Controller
this.getStore('Products');
Ext.getStore('Products');

删除这些函数可以加快应用程序启动速度,因为框架不再需要为每个 Controller 中定义的每个模型和视图生成一个函数。这也意味着 MVC 的约定与框架其余部分的约定相匹配,从而产生更可预测的 API。

Sencha Touch 2.4