文档帮助

术语、图标和标签

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

访问级别

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

成员类型

成员语法

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

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

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

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

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

参数

item :  Object

正在添加的配置对象。

返回值
Ext.Component

要添加的组件。

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

成员标志

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

类图标

- 表示一个框架类

- 一个单例框架类。*有关更多信息,请参阅单例标志

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

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

成员图标

- 表示类型为 config 的类成员

- 表示类型为 property 的类成员

- 表示类型为 method 的类成员

- 表示类型为 event 的类成员

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

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

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

类成员快速导航菜单

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

Getter 和 Setter 方法

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

历史记录栏

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

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

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

搜索和过滤器

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

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

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

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

API 文档类元数据

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

展开和折叠示例和类成员

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

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

桌面 -vs- 移动视图

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

查看类源代码

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

Cmd


顶部

创建 Sencha Cmd 包

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" 文件夹中,因为

  • 它是您的包文件夹的 ZIP 文件。
  • 包的用户不需要它。

"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 都可以工作。

Cmd