The All New Sencha Cmd

Many exciting things have been happening internally on the build tools for Sencha frameworks.

Some weeks ago we decided to reorganize our development of Sencha Cmd around a very exciting proof-of-concept: a framework-aware, JavaScript compiler (the new name for “SDK Tools” a.k.a. “Sencha Command”).

The gains from just the first few optimizations were so promising that we decided to accelerate the release of this technology and focus the Sencha Cmd team on bringing the compiler out of the lab and into your applications as quickly as possible. Along the way, of course, we will be fixing as many of the bugs reported against version 2 as we can.

We have also added numerous new guides on how to use Sencha Cmd with your Ext JS and Sencha Touch applications, and you can find them here.

As usual, please provide any feedback you may have regarding Sencha Cmd and the documentation through our forum.

The View From Inside Sencha

For several reasons we have consolidated many of the tools in Sencha Cmd into Java. Since Java has always been a system requirement for doing builds, this may go unobserved by most. This transition has really helped us leverage perhaps the most exciting highlight to share: the recent (and large) upgrade to our internal Continuous Integration (CI) system. All of this newly added capacity not only allows our product teams to continue to expand their test coverage, but also allows us to add Sencha Cmd to the mix.

With Java we are able to easily monitor detailed code coverage generated by the CI system for all of the functionality in Sencha Cmd. We can also watch the performance trends for some of the more expensive operations to keep your build cycle times down. I am happy to report that, at the present time, we have approximately 70% code coverage (by line) and expect to significantly increase that number as we audit the uncovered areas of the code throughout the beta process.

OK, so enough talk about us! On to the good stuff. :)

Introducing Sencha Cmd V3

The following is a high-level summary of the major features of Sencha Cmd V3. I will expand on several of these. This should be somewhat familiar to those who have used the previous releases, but many things are all new or significantly expanded.

• Code generation tools to generate entire applications and extend those applications with new MVC components, for both Ext JS and Sencha Touch.
• A framework-aware, JavaScript compiler that knows the semantics of Sencha frameworks
  and can produce minimal footprint builds from your source. In the future, the compiler
  will optimize many of the high-level semantics provided by Sencha frameworks to reduce
  load-time of your applications.
• Sencha Mobile Packager provides a way to seamlessly “package” your web app in a native shell and instantly making it app-store-ready.
• Powerful code selection tools for tuning what is included in your application’s final
  build, determine common code across pages and partition shared code into “packages”—all
  using high-level set operations to get builds exactly as you want them.
• Workspace management to assist in sharing code between pages or applications.
• Image extraction to convert CSS3 features (such as border-radius and linear-gradient)
  into sprites for legacy browsers.
• Flexible configuration system allows defaults to be specified for command options at
  the application or workspace level, or across all workspaces on a machine.
• Robust logging to help understand the inner workings of commands and facilitate
  troubleshooting.
• Integration with Apache Ant.
• Code generation hooks that can be specific to one page or shared by all pages in the
  workspace (for example, to check coding conventions or guidelines as new models are
  generated).
• Reliance on significantly fewer third-party, native executables. This can be very helpful in large organizations that need IT approval for each one. Gone are HammerJS, Jsdb and Node.

Compiler vs. Builder

In previous versions of tooling, builds were basically just file concatenation. For Ext JS, this was driven by a “JSB” file that contained the list of source files to include in their proper order. This file was maintained in part by hand and in part using tools that would run your application to determine its requirements. Things are similar in Sencha Touch where app.json is used.

Using the new compiler, all of this information is read directly from your application’s source code and the source code of the framework. One of the main benefits of this global view of the source is that the compiler can provide helpful, code-level diagnostic messages.

To get the complete view of your Ext JS applications, the compiler can now also process script tags in a section of your markup that you specify. In future releases, this will enable Sencha Cmd to inject conditional logic directly in your markup to eliminate a round-trip before loading other dependencies.

The high-level, application commands have all been adapted to use the compiler, so you won’t need to change anything if you are using commands like sencha app build. If your application was not produced with sencha generate app or moving your code into that structure is not an option for you, then there are new commands that expose the compiler’s features directly.

Ext JS Code Generation

A feature that Sencha Touch users have had for some time is code generation. Sencha Cmd now provides the same level of support for application, model, view and controller code generation for Ext JS. This can help accelerate new projects by removing the need to hand-craft all the boilerplate. It also provides consistency for team members.

The process starts like so:

sencha -sdk /path/to/extjs generate app MyApp /path/to/app

Various other commands, like sencha generate model and sencha generate controller, will extend the generated application. When you are ready, sencha app build produces the build.

One of the most useful features provided to generated Ext JS applications is that Sencha Cmd maintains a “bootstrap” file containing important metadata about your application’s source code. This file is included in the generated HTML file and takes care of setting up paths for the dynamic loader as well as informing the loader of all classes in your application. Formerly, this metadata was only available for framework code and it is what enables the following code to work:
Ext.define(‘MyApp.foo.Bar’, {
requires: [
‘Ext.grid.*’, // this worked previously
‘MyApp.util.*’, // but now this works!
],
// …
});

Further, you won’t need to call Ext.Loader.setPath anymore since all that information is maintained in the bootstrap file.

The only issue to contend with is that the metadata contained in the bootstrap file becomes stale when you add, remove or rename classes or namespaces. All that is required to update your application’s metadata is to run this command from your application folder:

sencha app refresh

This functionality is only supported for Ext JS today, and will likely be extended to Sencha Touch in subsequent releases. To see how you can use the compiler to generate a bootstrap file yourself. see the Single-Page Ext JS Apps guide.

Using Workspaces To Share Code

A common request from folks building large applications containing multiple pages is to have a convenient way to share code between pages. Even more common is to be able to share code between your Ext JS and Sencha Touch front-ends.

The new workspace feature enables organizations to manage shared code and configuration across multiple pages. While a workspace is little more than a folder that contains a .sencha folder (with content understood by Sencha Cmd), a workspace enables Sencha Cmd to find common configuration information for all pages contained anywhere inside the workspace.

The most common thing to do is to set a default “classpath” for the compiler so that all compile commands will find shared code. Once a folder is added to the workspace classpath, it will automatically be searched when compiling any page in the workspace.

Sencha Mobile Packaging

Sencha Cmd includes the latest and greatest version of the Sencha Mobile Packager. This is the new name for the “Native Packager” to align it with the exciting and new Sencha Desktop Packager included in the Sencha Complete: Team bundle.

The Sencha Mobile Packager is installed as part of Sencha Cmd, so once you have Sencha Cmd V3 installed, you are ready to go. A welcome relief for some: this installation no longer requires administrative permission.

The Compiler

To build an Ext JS application, say in the structure produced by Sencha Architect, you need run only a command like this:

sencha compile -classpath=app.js,app,ext/src 
             page -in=app.html -out=build/index.html

There are only a couple requirements to meet for the compiler to be able to do its work.

First, you must use requires where appropriate to avoid any kind of synchronous loading during development. This is really no different than the current tools and recommendations, so this may not require any changes to your application.

Second, you will need to add some new directives to your markup (HTML or ASPX or JSP or PHP or …) file:

These comments allow the compiler to identify the scripts at the “root” of your application (in this case, app.js) as well as ignore the “bootstrap” part of the framework you use in development. This file includes a minimal amount of the framework and primes the dynamic loader. In a compiled application, all of these same files are pulled in by the dependency process.

This section of the markup file will be replaced by a single script tag to the generated all-classes.js file that will be placed in the same folder as the markup file.

A Deeper Look

Some folks occasionally need to perform custom builds of the framework. For example, they may have applied a patch to the source. In Ext JS 4.1.1a and 4.1.2a, we now ship a build script that enables this command:

sencha ant build

This will build the standard set of “ext*.js” files from the contents of the src folder. To see the compiler commands required to build the framework from source, you can examine the provided build.xml file.

Custom builds can be made using the compiler directly. To illustrate, let’s create a build that we have occasionally contemplated adding: ext-all-no-charts.js. Now with the compiler, this can be accomplished with this command:

sencha compile -classpath=ext/src 
                exclude -namespace Ext.chart and 
                concat -out ext-all-no-charts-dev.js and 
                -option debug:false 
                concat -out ext-all-no-charts-debug.js and 
                concat -yui -out ext-all-no-charts.js

Breaking this down, we can see several advanced features of Sencha Cmd at work. In particular the use of “command chaining”. The and command conjunction tells Sencha Cmd to continue processing arguments against the current command category. In the above example, that is the compile command.

The first part loads up the compiler and tells it the folder for source (i.e., the “classpath”). In this case, we are pointing at an extracted Ext JS SDK in a folder named ext:

sencha compile -classpath=ext/src

The above will automatically include all files in the classpath as part of the “current set” of files. Since we don’t want charts, we exclude the namespace:

exclude -namespace Ext.chart and

We then concatenate out (in their proper order) to ext-all-no-charts-dev.js:

concat -out ext-all-no-charts-dev.js and

We chain the above command using and, so we are now continuing at the compile command. We reconfigure the options to remove debug code.

-option debug:false

The set of files is the same, but their content will be somewhat different and we concatenate the result to ext-all-no-charts-debug.js.

concat -out ext-all-no-charts-debug.js and

Another and to continue back at the compile command, so we again concat, but this time we enable the YUI Compressor.

concat -yui

Writing the compressed output to ext-all-no-charts.js.

-out ext-all-no-charts.js

Theme Building for Ext JS

Building image sprites for custom themes has always been somewhat complex and error prone. Because this is critical for supporting legacy browsers while taking advantage of CSS3 features such as border-radius and linear-gradient, we have revamped this process.

In Sencha Cmd, this now begins with an HTML page that you can open in a CSS3-compatible browser like Firefox or Chrome. So you can then make sure your theme is rendering properly before generating image sprites.

The architecture for theme pages is designed to make including custom components a simple task. Over time, we hope to see custom component providers supply “theme building” definition files to go along with their components. This would enable their users to easily incorporate those components into custom themes.

Getting the Beta

Hopefully all of that has you excited to try out the beta of Sencha Cmd. We really depend on, and greatly appreciate, your feedback to help us ensure that Sencha Cmd meets your needs.

For Sencha Touch 2.1 Beta 3, you just need to download the latest Sencha Touch SDK and Sencha Cmd. For Ext JS applications, you will need either Ext JS 4.1.1a or Ext JS 4.1.2a. These releases has very few changes beyond what is required to work with Sencha Cmd. This chiefly amounts to some added compiler directives (just comments) to key files, plus a sencha.cfg file required for Sencha Cmd.

You can download the Ext JS 4.1.1a from the Ext JS product download page.

Ext JS 4.1.2a is available from the Sencha Support Portal.

The latest beta refreshes can be found on the forum here.

Conclusion

We are very excited to hear about your experience with the new Sencha Cmd. Tell us the good and the bad (so we can fix it!). We want this version to enhance and streamline your development experience with Sencha frameworks!