expand
Contents Prerequisites What’s a Workspace? Generating a Workspace Configuration Framework Locations Generating Pages Building Applications Packages Next Steps

Sencha Cmd 的 Workspace

此向导介绍了 Sencha Cmd 中的 Workspaces. Workspaces 是为了多个需要共享框架、代码、样式和资源的应用程序而设计的.

前提

推荐先阅读下面的向导:

什么是 Workspace?

开发大型应用程序，首先都是和开发单页应用一样的步骤. 一旦项目扩充到需要多页应用, 一些共同的问题就出现了:

  • 使用同一份 framework 框架 (Ext JS and/or Sencha Touch).
  • 跨单页应用共享代码
  • 共享第三方包 (packages).

为了实现这些目的, Sencha Cmd 引入了“Workspace”这一概念. Workspace就是一个文件夹，包含了framework、多个extjs/touch应用、包packages、共享代码和文件. Workspace根目录的位置应该要满足你的源代码管理的需求. 任何创建在Workspace根目录下的的 应用程序/页面 子目录，不管目录深度，都视为此Workspace的成员 .

虽然不是必须的, 不过一般源码管理仓库的根目录就是Workspace.

Workspace里面的各个单页应用的所处的目录结构，对sencha cmd来说并不重要, 不过接下来的示例中，每个单页应用都是作为Workspace的直接子目录的.

名词解释. “应用程序” 这个词可能会令人困惑，因为它在不同的结构下有不同的意义和范围. 对于Sencha 框架来说, 一个“应用程序”就是一个web页面. 通常政协应用程序通过调用Ext.application() 来加载页面. 如果一个项目需要多页面, 一般这些页面会一起统称为 “应用程序”. 为了这篇向导的需要, 我们用第一种理解：一个页面就是一个应用程序.

创建一个 Workspace

要创建一个 Workspace, 使用下面的cmd命令:

sencha generate workspace /path/to/workspace

会产生下面的目录结构.

workspace.json          # 此 Workspace 的 JSON 描述文件
.sencha/                # Sencha 的特定文件 (比如configuration配置)
    workspace/          # Workspace 的特定内容 (看下面)
        sencha.cfg      # Workspace 的配置文件, 用于Sencha Cmd
        plugin.xml      #  Workspace 的 Plugin, 用于Sencha Cmd

配置

和应用程序的配置一样. "app.json" 文件控制单个应用程序, 而 "workspace.json" 文件控制 Workspace 下的所有应用程序.

Framework 的位置

Sencha Ext JS 或 Sencha Touch 的位置 (也即是“SDK” 或者 “framework”) 是作为 Workspace 的一个配置项的. 这让所有应用程序都可以共享这个配置. 不同的开发团队可能设置成不同的位置而不管 Sencha SDK 有没有存放在源码管理系统上. 下面的设置，让你可以控制你的 Workspace 中 Sencha SDK 的位置.

默认情况下, 一个 Workspace 同时具有 Sencha Ext JS 和 Sencha Touch SDK. 这些配置项存放在".sencha/workspace/sencha.cfg"，内容如下:

ext.dir=${workspace.dir}/ext
touch.dir=${workspace.dir}/touch

workspace.dir 配置由 Sencha Cmd 决定，如果需要可以自行扩展. 换句话说, 默认情况下, 一个 Workspace 包含了 SDK 的副本, 这个 SDK 副本需要被各个应用程序使用.

应用程序通过 framework 配置项来引用 framework, 此配置项在应用程序的"app.json" 文件中:

"framework": "ext"

创建页面

一旦创建了一个Workspace, 就可以像先前说的创建 页面 (“应用程序”) 了，只要使用 “ext” 即可指定SDK框架:

cd apps
sencha -sdk ../ext generate app NewExtApp new-app

或者, 使用 --ext 开关来指定 “ext” 框架而不用担心具体路径:

cd apps
sencha generate app --ext NewExtApp new-app

因为这些应用都创建在 Workspace 里面, 所以有下面的目录结构 (和单页应用结构明显不一样):

workspace.json              # 此 Workspace 的 JSON 描述文件
.sencha/                    # Sencha 的特定文件 (比如configuration配置)
    workspace/              # Workspace 的特定内容 (看下面)
        sencha.cfg          # Workspace 的配置文件, 用于Sencha Cmd
        plugin.xml          # Workspace 的 Plugin, 用于Sencha Cmd

ext/                        # Ext JS SDK 的副本
    ...

touch/                      # Sencha Touch SDK 的副本
    ...

extApp/
    .sencha/                # Sencha 的特定文件 (比如configuration配置)
        app/                # App 的特定内容 (看下面)
            sencha.cfg      # 配置文件, 用于Sencha Cmd
    app.json                # App 的 JSON 描述文件

touchApp/
    .sencha/                # Sencha 的特定文件 (比如configuration配置)
        app/                # App 的特定内容 (看下面)
            sencha.cfg      # 配置文件, 用于Sencha Cmd
    app.json                # App 的 JSON 描述文件

build/                      # build输出目录.
    production/             # build production输出目录
        touchApp/
        extApp/
    testing/                # build testing输出目录
        touchApp/
        extApp/

项创建更多页面, 重复上面的命令即可.

打包应用程序

打包一个和多个应用程序的过程没有区别. 进入到各个应用程序目录下，执行:

sencha app build

效率起见, 你可以创建一个批处理.

包 Packages

Sencha Cmd 提供了很强大的包管理功能，可以用来下载并集成JavaScript, 样式和文件包到你的应用程序中.

workspace.json      # 此 Workspace 的 JSON 描述文件
    packages/       # shared Cmd 包的目录
        local/      # 本地创建的包
        remote/     # 网上下载的包

通常, "packages/remote" 目录会被源码管理器忽略，因为它们总是可以从网上下载到.

注意: 以前发布的版本中, 所有的包都位于 "packages" 目录下. 这种分离（大多数情况下都对项目有帮助）, 可以在 "workspace.json" 里面改.

下一步

推荐先阅读下面的向导:

Last updated