许多类在使用配置对象创建(实例化)类时都有快捷名称。快捷名称被称为 alias
(如果类扩展了 Ext.Component,则为 xtype
)。alias/xtype 在适用类的类名旁边列出,以便快速参考。
框架类或其成员可以指定为 private
或 protected
。否则,类/成员为 public
。Public
、protected
和 private
是访问描述符,用于说明类或类成员应该如何以及何时使用。
Public 类和类成员可供任何其他类或应用程序代码使用,并且在主要产品版本中可以作为稳定且持久的部分被依赖。Public 类和成员可以通过子类安全地扩展。
Protected 类成员是稳定的 public
成员,旨在由拥有类或其子类使用。Protected 成员可以通过子类安全地扩展。
Private 类和类成员在框架内部使用,不供应用程序开发人员使用。Private 类和成员可能会随时更改或从框架中省略,恕不另行通知,并且不应在应用程序逻辑中依赖它们。
static
标签。*请参阅下面的静态部分。下面是一个类成员示例,我们可以对其进行剖析,以展示类成员的语法(在本例中,是从 Ext.button.Button 类查看的 lookupComponent 方法)。
让我们看一下成员行的每个部分
lookupComponent
)( item )
)Ext.Component
)。对于不返回除 undefined
之外任何内容的方法,可以省略此项,或者可以显示为以斜杠 /
分隔的多个可能值,表示返回的内容可能取决于方法调用的结果(即,如果 get 方法调用成功,方法可能返回 Component,如果失败,则返回 false
,这将显示为 Ext.Component/Boolean
)。PROTECTED
- 请参阅下面的标志部分)Ext.container.Container
)。如果成员源自当前类,则源类将显示为蓝色链接;如果它从祖先类或混入类继承,则显示为灰色。view source
)item : Object
)。undefined
之外的值,则“返回值”部分将注明返回的类或对象类型以及描述(在本例中为 Ext.Component
)Available since 3.4.0
- 示例中未显示),就在成员描述之后Defaults to: 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 文档页面顶部的类名来查看类源代码。可以通过单击成员行右侧的“view source”链接来查看类成员的源代码。
Sencha Cmd 包含了 Sencha Package Manager。即使您不打算分发您创建的包,包也有许多用途。本指南介绍了创建您自己的包以及分发它们的过程。有关使用包的信息,请参阅 Sencha Cmd 包。
在我们生成新包之前,我们必须首先为其创建一个家:一个 Workspace。对于此示例,我们将为此包使用 Ext JS,因此我们从以下命令开始
sencha -sdk /path/to/ext-n.n.n generate workspace /path/to/workspace
现在我们导航到新的工作区并生成包
cd /path/to/workspace
sencha generate package foo
以上步骤生成一个启动器包,其中包含许多常用的部分。您可以删除其中的许多部分,但保持 ".sencha"
文件夹完整非常重要。
由 sencha generate package
生成的包的结构如下
packages/
local/
foo/ # Top-level folder for the package
.sencha/
package/
sencha.cfg # Sencha Cmd configuration for this package
build-impl.xml # Generated build script for package
plugin.xml # Sencha Cmd plugin for this package
codegen.json # Data to support 3-way merge in code generator
classic/ # Classic toolkit-specific src code
examples/ # Example applications demonstrating the package
licenses/ # License agreement
modern/ # Modern toolkit-specific src code
overrides/ # Folder for automatically activated overrides
resources/ # Static resources (typically has images folder)
sass/ # Container for styling code
etc/ # General, non-component oriented styling
example/ # - internal use
src/ # Style rules named by component
var/ # Variables and mixins named by component
src/ # Folder for normal JavaScript code
build.xml # Build script (called by `sencha package build`)
package.json # Package descriptor
Readme.md # High-level information about this package
虽然上面内容相当广泛,但作为包的唯一必需部分是 "package.json"
和 ".sencha/package/sencha.cfg"
。
"package.json"
文件包含包的描述。以下是 "theme-neptune"
包中的一个示例
{
"name": "theme-neptune",
"type": "theme",
"creator": "Sencha",
"summary": "Ext JS Neptune Theme",
"detailedDescription": "The Neptune Theme provides a clean, modern style for Ext JS",
"version": "n.n.n",
"compatVersion": "n.n.n",
"format": "1",
"extend": "theme-neutral"
}
creator
属性是您需要作为包作者设置的内容。此文本没有验证,但它必须与您稍后讨论的分配给本地包仓库的名称匹配。
大多数包的目的是(最终)集成到应用程序中。为了实现这一点,Sencha Cmd 在 sencha app build
过程中将每个必需包的各个部分合并到应用程序中。
这具体如何发生取决于包的 type
。
不同类型的包扮演不同的角色。Sencha Cmd 理解以下类型的包
code
- 供应用程序或其他包使用的任意代码包。这些包是通用的,并且在存在选择它们的 require
语句时包含在内。theme
- 用作应用程序主题的包。主题是特殊的,因为在构建中只允许一个 theme
类型的包处于“活动”状态。此主题由 app.json
中的 theme
属性选择。主题还可以使用 extend
从另一个主题包继承样式和资源。locale
- 此包类型已弃用,取而代之的是标准的 code
包,其中包含 classpath
中的 theme.name
。有关示例,请参阅 Ext JS locale
包。"src"
文件夹是放置类(如自定义组件或其他有用的代码)的地方。此代码会自动包含在应用程序或其他包的 classpath
中,以便 require
和使用。
您可能会将大部分 JavaScript 代码放在这里。放置在此文件夹中的类应遵循 编译器友好的代码准则。
"sass"
文件夹包含三个子文件夹,旨在处理样式编译的不同方面。
"sass/etc"
- 与 JavaScript 类没有直接关系的代码"sass/var"
- 变量定义(镜像 JavaScript 类层次结构)"sass/src"
- Mixins 和规则(镜像 JavaScript 类层次结构)"sass/var"
和 "sass/src"
中的文件夹和文件的组织方式使其成为它们所应用的 JavaScript 类的镜像。这种对应关系允许 Sencha Cmd 包含应用程序所需的文件。由于该过程通过将 JavaScript 类层次结构映射到文件系统而不是扫描这些文件夹来完成,因此不符合此要求的文件永远不会包含在内。
名称对应关系由 "package.json"
中的 namespace
属性驱动
{
"name": "MyPkg",
...
"sass": {
"namespace": "MyPkg",
...
}
当将所需 JavaScript 类的类名映射到相应的 .scss
文件时,命名空间就会发挥作用。例如,给定类 MyPkg.foo.Bar
和上面的 namespace
,Sencha Cmd 删除“MyPkg.”并在 "sass/var"
和 "sass/src"
文件夹中查找“foo/Bar.js”的相对路径。
注意: 即使 Fashion 不是 Sass 的实现,为了兼容性,仍保留“sass”配置名称。
"resources"
文件夹是您放置包所需的静态资源的地方。当应用程序使用包时,它们会将这些资源复制到它们自己的 "resources"
文件夹的子文件夹中,该子文件夹以包名称命名。在本例中为 "resources/foo"
。如果您使用提供的 theme-background-image
方法,则 CSS 文件中使用的相对路径将自动更正。
"overrides"
文件夹专门用于您的包提供强制覆盖,因此得名。应谨慎使用此机制,因为您放置在此文件夹中的所有代码都将自动要求任何使用此包的应用程序。
Ext JS Neptune 主题使用此机制来更改各种组件上的某些默认配置属性。Locale 包使用此机制将它们自己的文本注入到各种组件的原型中,或者为日期格式化等内容提供特定于语言环境的逻辑。
包有一个 version
属性,用于描述其当前版本号。除了当前版本(在 version
属性中),包还可以使用 compatVersion
属性指示它们向后兼容的程度。
这些版本在解析包需求时使用。包的每个版本都应具有更新的版本号。Sencha 分配给版本号的含义可能会对您有所帮助
x.y.z.b
x = Major release number (large, impacting changes and features)
y = Minor release number (new functionality but few if any breaking changes)
z = Patch release number (bug fix / maintenance release - goal of 100% compatible)
b = Build number (assigned by build system)
version
属性通常最容易维护。但是,compatVersion
是关于用户应能够在多大程度上透明地升级而无需代码更改的有意声明。
包可以像应用程序可以要求包一样要求其他包。为此,您需要添加到 requires
数组
{
"name": "bar",
"type": "code",
"creator": "anonymous",
"summary": "Short summary",
"detailedDescription": "Long description of package",
"version": "1.0.0",
"compatVersion": "1.0.0",
"format": "1",
"local": true,
"requires": [
'ext-easy-button'
]
}
注意:当作为包作者使用版本限制时,重要的是要考虑到应用程序和所有必需的包都必须就通用版本达成一致。如果您过于限制,此过程可能会无法为所有必需的包找到双方都同意的版本。
包继承的概念专门用于主题。以下是将继承的包内容滚入派生包的最重要方式
"resources"
文件夹被复制到 "build"
输出文件夹中的 "resources"
文件夹中。overrides
会自动包含在派生包的构建输出中。要发布包,您需要使用以下命令构建它
sencha package build
这会在包内生成一个 "build"
文件夹。当应用程序在“开发模式”(未经编译)下运行时,这是必需的。
它还在您工作区的 "build"
文件夹中生成 "foo.pkg"
文件。此文件未放置在包的 "build"
文件夹中,因为
"foo.pkg"
文件用于将包添加到您的本地仓库。请参阅下文。
您需要手动将 package.framework 指定添加到您的 "package.json"
文件中。
"framework": "ext"
您需要手动将 package.theme 指定添加到您的 "package.json"
文件中。该值将是用于生成的 CSS 的主题包的名称。
"theme": "theme-triton"
本地仓库在 Sencha Cmd 包 中介绍过,但是当您想要分发您创建的包时,还有更多需要了解的内容。
由 Sencha Cmd 生成的本地仓库看起来像这样
.sencha/
repo/
sencha.cfg # Sencha Cmd configuration for the repo
plugin.xml # Plugin for repository hooks
private-key.json # Private key for repo
remotes/ # Storage for remote repositories
remoteName/ # Name given at `sencha repo add`
catalog.json # Last catalog from this remote
trust/ # Unused in this release
<somename>.cert.json # Copy of `cert.json` (a public key)
pkgs/
catalog.json # Catalog of all packages in this repo
cert.json # Public key for this repo
Foo/
catalog.json # Catalog for all versions of Foo package
cert.json # Public key for creator of Foo package
1.0/ # Folder containing version 1.0
Foo.pkg # Zip file of package
package.json # Extracted package descriptor
1.1/
...
Bar/
...
当 Sencha Cmd 生成默认本地仓库时,它不要求您提供任何类型的身份。这对于它作为缓存的角色来说很好,但是作为包作者,您需要在您发布的包上署名。在您可以发布包之前,您需要使用身份初始化您的本地仓库
sencha package repo init -name "My Company" -email "[email protected]"
完成此步骤后,您的姓名和电子邮件地址将与新的 公钥/私钥对 一起记录在本地仓库中。
注意:name
参数必须与您在 "package.json"
中设置的 creator
属性的值匹配。
您的姓名、电子邮件和公钥存储在 "pkgs/cert.json"
文件中。此文件将自动添加到您创建的包中,以标识您为包作者。
显然,根据其名称,您的私钥不打算与他人共享。它存储在您的本地仓库中的 ".sencha/repo/private-key.json"
中。
您可能需要备份这两个文件,因为它们将在未来的版本中发挥更重要的作用。
"pkgs"
文件夹是存储所有包的地方。这些可能是您创建的包或您下载的包。
当您添加包 ".pkg"
文件时,这些文件将被复制到 "pkgs"
文件夹树中。
".sencha/repo/plugin.xml"
文件是一个 Ant 脚本,您可以使用它为仓库操作(例如 sencha package add
)提供“钩子”。有关此内容的更多详细信息,请参阅生成文件中的注释。
一旦您从构建中获得了 ".pkg"
文件,并假设您在本地仓库中设置为身份的 name
与您在 "package.json"
中定义的 creator
属性匹配,您就可以运行此命令
sencha package add foo.pkg
Sencha Cmd 将使用您的私钥生成 ".pkg"
文件的哈希值,并将其添加到您指定的 ".pkg"
文件中,然后将该文件复制到本地仓库。
现在包驻留在仓库中,如果其他开发人员已将您的仓库添加为远程仓库,则他们可以 require
它。
请求 Sencha 将您的 ".pkg"
添加到 Sencha 包仓库的过程仍在最终确定中,但您可以查看 Sencha Market 以获取有关此内容的更新。
"pkgs"
文件夹的结构是远程仓库预期的结构。其他人 require
您创建的包所需做的就是添加远程仓库
sencha package repo add my-company http://my.company.com/packages
也就是说,假设您已将 "pkgs"
文件夹内容托管在上述 HTTP URL 上。除了 HTTP GET 访问之外,该托管没有任何要求,因此静态文件服务器或 CDN 都可以工作。