依赖项和 MVC
许多类都有在使用配置对象创建（实例化）类时使用的快捷名称。快捷名称称为别名（如果类扩展 Ext.Component，则称为xtype）。对于可应用的类，别名/xtype 会列在类名称旁边以供快速参考。
框架类或其成员可以指定为私有或受保护。否则，类/成员为公有。公有、受保护和私有是用于传达如何以及何时应该使用类或类成员的访问描述符。
公有类和类成员可供任何其他类或应用程序代码使用，并且可以作为主要产品版本中稳定且持久的存在。公有类和成员可以通过子类安全地进行扩展。
受保护类成员是稳定的公有成员，旨在由拥有类或其子类使用。受保护的成员可以通过子类安全地进行扩展。
私有类和类成员由框架内部使用，不打算由应用程序开发人员使用。私有类和成员可能会在任何时候更改或从框架中省略，且不应在应用程序逻辑中依赖它们。
static标签。*请参见下文的静态。下面是一个示例类成员，我们可以对其进行剖析以显示类成员的语法（在这种情况下，从 Ext.button.Button 类中查看的 lookupComponent 方法）。
我们来看看成员行中的每一部分
lookupComponent）( item )）Ext.Component）。对于不返回 undefined 以外任何内容的方法，可以省略此项，或者可能显示用正斜杠 / 分隔的多个可能值，表示返回的内容可能取决于方法调用的结果（即，如果 get 方法调用成功，则方法可能返回一个组件，如果失败则返回 false，将显示为 Ext.Component/Boolean）。PROTECTED - 请参阅下面的标志部分）Ext.container.Container）。如果成员源自当前类，则源类将显示为蓝色链接；如果成员是从祖先或混合类继承的，则显示为灰色。查看源）item : Object）进行列出。undefined 以外的值，则“返回”部分将注明返回的类或对象类型以及描述（在此示例中为 Ext.Component）自 3.4.0 起可用 - 示例中未显示）默认为：false）API 文档使用许多标志来进一步传达类成员的功能和意图。标签可以用文本标签、缩写或图标表示。
classInstance.method1().method2().etc();false，则不会触发- 表示框架类
- 单例框架类。*有关更多信息，请参阅单例标志
- 组件类型框架类（Ext JS 框架中任何扩展 Ext.Component 的类）
- 表示当前查看的版本中类、成员或指南是新的
- 表示类型为 config 的类成员
- 表示类型为 property 的类成员
- 表示类型为 method 的类成员
- 表示类型为 event 的类成员
- 表示类型为 theme variable 的类成员
- 表示类型为 theme mixin 的类成员
- 表示当前查看的版本中类、成员或指南是新的
在 API 文档页面中类名称的正下方是与当前类拥有的成员类型相对应的按钮行。每个按钮显示按类型划分的成员数（此计数会在应用筛选器时更新）。单击按钮将导航到该成员部分。将鼠标悬停在成员类型按钮上将显示弹出菜单，其中包含该类型的所有成员，以便快速导航。
与类配置选项相关的 Getter 和 Setter 方法将显示在方法部分以及 API 文档和成员类型菜单中配置部分的正下方。Getter 和 Setter 方法文档将位于配置行中，以便于参考。
您的页面历史记录保存在本地存储中，并显示在顶部标题栏正下方（使用可用空间）。默认情况下，仅显示与您当前查看的产品/版本匹配的搜索结果。您可以通过单击历史记录栏右侧的 按钮并选择“全部”单选按钮来展开显示内容。这将显示历史记录栏中所有产品/版本的所有近期页面。
在历史记录配置菜单中，您还将看到最近访问的页面列表。结果将按“当前产品/版本”和“全部”单选按钮选项进行筛选。单击 按钮将清除历史记录栏以及保存在本地存储中的历史记录。
如果在历史记录配置菜单中选择了“全部”，则将启用“在历史记录栏中显示产品详细信息”复选框选项。选中后，每个历史记录页面的产品/版本将与历史记录栏中的页面名称一起显示。将光标悬停在历史记录栏中的页面名称上也将以工具提示的形式显示产品/版本。
可以使用页面顶部的搜索字段搜索 API 文档和指南。
在 API 文档页面上，还有一个筛选器输入字段，它使用筛选器字符串筛选成员行。除了按字符串筛选外，您还可以按访问级别、继承和只读筛选类成员。这是使用页面顶部的复选框完成的。
API 类导航树底部的复选框筛选类列表以包括或排除私有类。
单击空搜索字段将显示您最近的 10 次搜索，以便快速导航。
每个 API 文档页面（Javascript 基本类型页面除外）都有一个与该类相关的元数据的菜单视图。此元数据视图将包含以下一个或多个
Ext.button.Button 类有一个备用类名称 Ext.Button）。备用类名称通常用于保持向后兼容性。默认情况下，可运行的示例（Fiddles）在页面上展开。您可以使用代码块左上角的箭头单独折叠和展开示例代码块。您还可以使用页面右上角的切换按钮切换所有示例的折叠状态。切换所有状态将在页面加载之间记住。
默认情况下，类成员在页面上折叠。你可以使用成员行左侧的箭头图标展开和折叠成员，或使用右上角的展开/折叠所有切换按钮全局展开/折叠。
在较窄的屏幕或浏览器上查看文档将导致针对较小尺寸优化视图。桌面和“移动”视图之间的主要区别是
可以通过单击 API 文档页面顶部的类名来查看类源。可以通过单击成员行右侧的“查看源”链接来查看类成员的源。
在 Sencha Touch 应用程序中，有两个主要位置可以定义依赖项 - 在应用程序本身或应用程序类中。本指南提供了一些有关在应用程序中声明依赖项的方式和位置的建议。
当你创建一个 MVC 应用程序时，Ext.application 为你提供了一种便捷的方式来指定应用程序使用的模型、视图、控制器、存储和配置文件。这是一个示例
Ext.application({
name: 'MyApp',
views: ['Login'],
models: ['User'],
controllers: ['Users'],
stores: ['Products'],
profiles: ['Phone', 'Tablet']
});
这五个配置选项是加载应用程序通常包含的文件类型（模型、视图、控制器、存储和配置文件）的便捷方式。指定这些配置意味着你的应用程序将自动加载以下文件
就加载的实体而言，上面的示例等效于手动定义如下依赖项
Ext.require([
'MyApp.view.Login',
'MyApp.model.User',
'MyApp.controller.Users',
'MyApp.store.Products',
'MyApp.profile.Phone',
'MyApp.profile.Tablet'
]);
当你向应用程序添加更多类时，这些配置在帮助你避免为每个文件输入完整的类名方面变得越来越有用。但是，请注意，其中三个配置不仅仅是加载文件 - 它们还执行以下操作
这意味着，如果您想利用 MVC 提供的所有便利性，
在定义应用程序依赖项时使用这些配置选项。
在使用设备配置文件时，您很可能有一些仅在某些设备上使用的类。例如，您的应用程序的平板电脑版本可能包含比手机版本更多的功能，这通常意味着它需要加载更多类。可以在每个配置文件中指定其他依赖项
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;
}
});
无论配置文件是否处于活动状态，在每个配置文件中指定的依赖项都会被加载。不同之处在于，即使它们已加载，应用程序也不知道如何执行其他处理，例如，如果配置文件不处于活动状态，则实例化特定于配置文件的控制器。
这可能听起来违反直觉 - 为什么下载不会使用的类？我们这样做是为了生成可部署到任何设备的通用产品版本，检测它应该使用哪个配置文件，然后启动应用程序。另一种方法是为每个配置文件创建自定义版本，创建一个可以检测设备应激活哪个配置文件然后下载该配置文件的代码的微加载器。
虽然通用版本方法意味着您正在下载不需要的代码，但对于绝大多数应用程序，这只会增加极少的额外大小。
对于较大的应用程序，通常将模型、视图和控制器拆分为子文件夹，以便保持项目的井然有序。这对于视图尤其如此 - 因为大型应用程序拥有超过一百个单独的视图类的情况并不少见，将它们组织到文件夹中可以使维护变得简单得多。
要在子文件夹中指定依赖项，请使用句点 (".") 来指定文件夹
Ext.application({
name: 'MyApp',
controllers: ['Users', 'nested.MyController'],
views: ['products.Show', 'products.Edit', 'user.Login']
});
在这种情况下，将加载以下五个文件
注意我们可以在此处的每个配置中进行混合和匹配 - 对于每个模型、视图、控制器、配置文件或存储，您可以指定类名的最后一部分（如果您遵循目录约定），或指定完整的类名。
我们可以通过完全限定要加载的类来指定应用程序外部的应用程序依赖项。一个常见的用例是在多个应用程序之间共享身份验证逻辑。也许您有几个通过公共用户数据库登录的应用程序，并且您希望在它们之间共享该代码。一种简单的方法是创建与您的应用程序文件夹并列的文件夹，然后将其内容作为应用程序的依赖项添加。
例如，假设我们的共享登录代码包含一个登录控制器、一个用户模型和一个登录表单视图，我们希望在应用程序中使用所有这些
Ext.Loader.setPath({
'Auth': 'Auth'
});
Ext.application({
views: ['Auth.view.LoginForm', 'Welcome'],
controllers: ['Auth.controller.Sessions', 'Main'],
models: ['Auth.model.User']
});
这将加载以下文件
前三个文件从应用程序外部加载，后两个文件从应用程序本身加载。
注意
在此示例中，加载器在我们的“Auth”文件夹中找到以“Auth”命名空间开头的类。我们可以将我们的公共 Auth 代码与应用程序文件夹一起放入我们的应用程序中，框架会找出如何加载所有内容。
在决定声明每个依赖项的位置时，一般规则是让您的类完全自包含。例如，如果您有一个包含其他几个视图的视图，则应在视图类中声明这些依赖项，而不是在应用程序中
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 中，依赖项通常在控制器中指定，以及在 Ext.application 调用中指定。虽然这种方法提供了一些便利性，但它也掩盖了系统的真实架构，并且将视图、模型和存储与控制器耦合得太紧密。以下示例显示了 1.x 中可用的代码
//1.x code, deprecated
Ext.regController('SomeController', {
views: ['Login'],
models: ['User'],
stores: ['Products']
});
这与在 Ext.application 中定义视图、模型和存储相同，但还提供了一些便利方法，以便在控制器中访问这些类。1.x 生成了两个函数 - getLoginView() 和 getUserModel() - 并公开了 getStore() 函数，该函数返回对在此控制器中定义的任何存储的引用。在 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');
删除这些函数可以加快应用程序启动速度，因为框架不再需要为每个控制器中定义的每个模型和视图生成一个函数。这也意味着 MVC 约定与框架其余部分的约定相匹配，从而产生更可预测的 API。
Sencha Touch | 使用条款