Ext.data.JsonP.command_workspace({"title":"Workspaces in Sencha Cmd","guide":"
Contents
\n\nThis guide shows how to use the new workspace feature of Sencha Cmd for building large\napplications that use multiple pages. This feature lets Sencha Cmd understand the pages,\nframeworks, and the shared code used by the various pages of your application. This\nenables Sencha Cmd to automate many common tasks.
\n\nThe process for building a large application starts off the same as the process for\nbuilding a single-page app. Before learning about the workspace feature for large\napplications, be sure to understand Sencha Cmd basics by reading\nUsing Sencha Cmd.
\n\nNote on terminology. Sencha frameworks-based applications, which employ MVC architecture,\ncall Ext.application
at the top of the code tree. This can be confusing because the\nframeworks use the term \"application\" to describe each page. In single-page applications,\nthese terms are interchangeable. When your application involves multiple pages, however,\nthis is not the case. This guide uses the term \"page\" in most cases because that is more\nfitting in this context.
New to Sencha Cmd V3 is the concept of a \"workspace\". A workspace is simply a folder that\ncontains one or more pages, frameworks, packages and other shared code or files. The\nlocation of the workspace root folder should be chosen to facilitate these needs as well\nas your source control requirements. Any generated applications/pages created in sub-folders\nof the workspace folder regardless of their depth are consider to be members of the workspace.
\n\nThough not a requirement, it is typically the case that the workspace folder is the root\nfolder in a source control repository.
\n\nThe exact organization of your pages inside your workspace is not important to Sencha Cmd.\nFor the sake of simplicity, however, the examples in this guide create all pages as immediate\nsub-folders of the workspace.
\n\nTo generate a workspace, use this command:
\n\nsencha generate workspace /path/to/workspace\n
\n\nThis will create the following structure in the specified folder.
\n\n.sencha/ # Sencha-specific files (e.g. configuration)\n workspace/ # Workspace-specific content (see below)\n sencha.cfg # Configuration file for Sencha Cmd\n plugin.xml # Plugin for Sencha Cmd\n
\n\nThe above directory structure should be familiar as it was part of the structure created in\nUsing Sencha Cmd. In this case, however, only the \".sencha/workspace\"\nfolder is created.
\n\nThe location of Sencha Ext JS or Sencha Touch (i.e., the \"SDK\" or \"framework\") is stored\nas a configuration property of the workspace. This allows multiple pages to share this\nconfiguration. Different teams will have different preferences on these locations and\nwhether or not the Sencha SDK's are stored in their source control system. The settings\ndiscussed below give you control over the location of Sencha SDK's in your workspace.
\n\nBy default, a workspace that has both Sencha Ex JS and Sencha Touch SDK's will have these\nproperty settings in \".sencha/workspace/sencha.cfg\"
:
ext.dir=${workspace.dir}/ext\ntouch.dir=${workspace.dir}/touch\n
\n\nThe value of the workspace.dir
property is determined by Sencha Cmd and is expanded as\nneeded. In other words, by default, a workspace contains a copy of the SDK's used by the\napplications it holds.
Applications reference their framework indirectly using the app.framework
property in\ntheir \".sencha/app/sencha.cfg\"
file:
app.framework=ext\n
\n\nOnce you have a workspace, generating pages (\"apps\") is the same as before:
\n\nsencha -sdk /path/to/ext generate app ExtApp /path/to/workspace/extApp\n
\n\nYou can also generate Sencha Touch applications in the same workspace:
\n\nsencha -sdk /path/to/touch generate app TouchApp /path/to/workspace/touchApp\n
\n\nBecause the target of these generated pages is in a workspace, the following structure\nwill be created (which is slightly different than for a single-page app):
\n\n.sencha/ # Sencha-specific files (e.g. configuration)\n workspace/ # Workspace-specific content (see below)\n sencha.cfg # Workspace's configuration file for Sencha Cmd\n plugin.xml # Workspace plugin for Sencha Cmd\n\next/ # A copy of the Ext JS SDK\n ...\n\ntouch/ # A copy of the Sencha Touch SDK\n ...\n\nextApp/\n .sencha/ # Sencha-specific files (e.g. configuration)\n app/ # Application-specific content\n sencha.cfg # Application's configuration file for Sencha Cmd\n\ntouchApp/\n .sencha/ # Sencha-specific files (e.g. configuration)\n app/ # Application-specific content\n sencha.cfg # Configuration file for Sencha Cmd\n\nbuild/ # The folder where build output is placed.\n extApp/ # Build output for ExtApp (by environment)\n production/\n testing/\n touchApp/ # Build output for TouchApp (by environment)\n production/\n testing/\n native/\n package/\n
\n\nTo generate more pages, repeat the above command. See the respective framework's\nUsing Sencha Cmd guide for details.
\n\nThe process for building each page of a multipage application is to run this command\nfrom each of the appropriate folders:
\n\nsencha app build\n
\n\nFor efficiency, you can create a script for this process, perhaps using Sencha Cmd's\nAnt Integration.
\n\nConfiguration is similar to what is described in Using Sencha Cmd.\nThe file \".sencha/app/sencha.cfg\"
holds configuration for one page (\"app\"). The most\nimportant of the properties found there is perhaps app.classpath
.
Unlike the single-page application, the \".sencha/workspace/sencha.cfg\"
file is now useful\nfor setting configuration properties for all pages in the workspace. The most important\nof these properties after framework locations is probably workspace.classpath
.
Settings found in multiple files are processed in \"first-write-wins\" fashion (as is normal\nfor Apache Ant scripts). This allows properties to be controlled at the command-line when\nnecessary. The order these files are loaded when present is as follows:
\n\n${app.dir}/.sencha/app/sencha.cfg
${workspace.dir}/.sencha/workspace/sencha.cfg
${ext.dir}/cmd/sencha.cfg
or ${touch.dir}/cmd/sencha.cfg
${cmd.dir}/sencha.cfg
By convention, the properties defined in the \"sencha.cfg\"
file for these \"scopes\" have\na common prefix. For properties at the Application scope (\".sencha/app/sencha.cfg\"
)\nstart with \"app.\" while those in the workspace scope (\".sencha/workspace/sencha.cfg\"
)\nhave the prefix \"workspace.\", frameworks use \"framework.\" and Sencha Cmd uses \"cmd.\".
Details on configuration properties can be found by reading the comments found in these\nfiles. The prefix should help you find where a property is defined.
\n\nMultipage applications commonly share code between pages. Using a workspace, you can use\nSencha Cmd to automatically scan shared code with the sencha app build
command. Here's\nhow to do that.
Let's add a common
folder to the workspace, like so:
.sencha/\n workspace/\n ...\ncommon/ # Folder for common things between pages.\n src/ # Folder for common JavaScript code for all pages.\n
\n\nTo include common/src
when building all pages in the application, add the follow to\n\".sencha/workspace/sencha.cfg\"
:
workspace.classpath=${workspace.dir}/common/src\n
\n\nThis adds the following component to the default classpath:
\n\n${framework.classpath},${workspace.classpath},${app.classpath}\n
\n\nBeyond sharing code between multiple Ext JS pages, or between multiple Sencha Touch\napplications, there is often the need to share code across the two Sencha frameworks.\nWhile the frameworks have a lot in common, they differ in many significant aspects,\nparticularly in the areas of UI components and layouts, which one would expect given that\nthey target such different device environments. Even with these differences, it's possible\nto share code between the two frameworks, for example, sharing code between two model\nclass definitions.
\n"});