Setting The Stage
In Sencha Cmd, applications exist in a Workspace. A Workspace is just a root folder of your choice where common things like applications, packages and Sencha frameworks reside. It is common to pick the root folder in source control to be the Workspace, but this is not required. For this article, we will create a test Workspace in an empty folder:
C:Test> md wksp C:Test> cd wksp C:Testwksp> sencha generate workspace . Sencha Cmd v18.104.22.168 ...
To get the ball rolling, let’s set up two Ext JS applications in this Workspace. By default, when we run “sencha generate app” we will get a Workspace as well as the application, and they will be in the same folder. That is, unless we generate the application in an existing Workspace, like the one we just created.
The following commands point Sencha Cmd at the Ext JS 4.2.1 downloaded and expanded zip file. The first Ext JS application we generate in the Workspace copies the necessary subset of the Ext JS SDK (or “framework”) into the “ext” folder. The second generated application does not need to do this as it will share the framework already in the Workspace.
C:Testwksp> sencha -sdk ../ext421 generate app ExtApp1 extApps/app1 Sencha Cmd v22.214.171.124 ... [INF] Workspace does not have framework ext at C:Testwksp ... copying ... C:Testwksp> sencha -sdk ext generate app ExtApp2 extApps/app2 Sencha Cmd v126.96.36.199 ...
Now, we have a Workspace, a subset of Ext JS and two empty applications in a folder structure that looks like this:
wksp/ ext/ (A copy of the necessary files for Ext JS) packages/ (Packages provided by Ext JS) extApps/ app1/ app2/ packages/ (A folder for non-framework packages)
Let’s Make A Package
Packages can be generated in a manner similar to applications like so:
C:Testwksp> sencha generate package common Sencha Cmd v188.8.131.52 ...
The key difference here is that the new package is placed in the “packages” folder:
wksp/ ... packages/ common/ resources/ sass/ src/ package.json ...
To make use of this package in our applications, we add it to their respective “app.json” files in the “requires” array:
"requires": [ "common" ]
What Does That Do?
And a package has this setting in its “.sencha/package/sencha.cfg” file:
To streamline these settings for use by applications, the information gleaned by the compiler is exported into what is called the “bootstrap”. If you are already familiar with the “Ext.Loader.setConfig” or “Ext.Loader.setPath” APIs, you won’t be needing them! Instead, you’ll find all the paths needed (and more) in your application’s “bootstrap.js” file.
This is not all that the package dependency accomplishes but that is enough for starters.
Using The Package
What’s next? A common (incorrect) assumption is that we must first build the package using “sencha package build” before it is useful to our applications. In fact, all that Sencha Cmd needs to use a package is knowledge of its classpath.
That means that the correct answer to this question is: we need to “refresh” the application’s bootstrap. If you are using the (new to Cmd v4) “sencha app watch” command then all of the necessary steps will be taken by restarting the watch. Adding package dependencies is not something that “sencha app watch” currently handles internally, so the manual restart is needed for now. As new classes are added to this package, however, app watch will detect these and automatically refresh the bootstrap.
While Sencha Cmd requires Java 6 for most functionality, “sencha app watch” depends on Java 7. If this is an issue, you can alternatively use the command that was available prior to Cmd v4: “sencha app refresh”. This command does exactly and only what is needed for this case. In Cmd v4, this is now just a convenient way to run the “refresh” target of the app build. In other words, “sencha app build” will also refresh the bootstrap… as well as build the Sass and a few other things.
What Does “sencha package build” Do?
The generated build script for packages (the implementation of “sencha package build”) handles two use cases: 1) produce a build of the package source for non-Cmd applications (similar to the “ext-all.js” file) and 2) prepare the package for distribution. Neither of these is required for a local package in a Workspace with Cmd-based applications, so we can ignore package builds entirely for this scenario.
These topics are covered thoroughly in the guides, so check them out for more details.
Packages With Components or Views
We have a Workspace with two (mostly) empty applications, the Ext JS SDK and a package named “common”. The applications are prepared to use any code we add to the common package, but things get interesting when we want to share complex things like custom components or perhaps Views for an MVC application. The complications come from the two “other” types of content needed to share such things: styles and resources (such as images).
Given that packages were originally designed to solve the requirements of themes, it should come as no surprise that packages can contain Sass source code (the dialect of “CSS++” used by Sencha frameworks) and that Sencha Cmd understands how to incorporate this code into your application’s build.