Sencha Ext JS 7.7 is Here – Discover What’s New and Exciting – LEARN MORE

Using Sencha Cmd in an Enterprise Application Development Workflow

March 26, 2014 2 Views

Sencha Cmd Enterprise Application Develpment Workflow As a member of the Sencha Professional Services team, I am often tasked with helping our customers start new projects based on the Ext JS and Sencha Touch frameworks.

More often than not, Sencha Cmd is the foundation of these projects — and while Sencha has documentation explaining its robust features, I find that it’s crucial to explain how Sencha Cmd fits into an application development workflow.

Before we dive into the workflow itself, let’s step back and explore what Sencha Cmd is and why it is so valuable for enterprise software development.

What is Sencha Cmd?

Sencha Cmd is a command-line suite of tools for building your Sencha applications. Although it has been a part of the Sencha toolbox for a few years, Cmd has recently matured into the cornerstone of Sencha application development.

From scaffolding a new project to minifying and deploying your application to production, Sencha Cmd provides a full set of lifecycle management features to complement your Sencha project. With a rich command line syntax and Ant integration, Cmd is perfect whether you want to integrate it into your enterprise build environment or use it by itself.

Why should enterprises use Sencha Cmd?

Beyond the obvious benefits of lifecycle management tools, apps built using Sencha Cmd have a standardized architecture. This means that apps are easy to maintain and upgrade — but it also means that all Sencha developers build apps the same way.

By standardizing the tools and the application architecture, enterprises can expect all Sencha applications to integrate with their internal systems consistently. Development and deployment can now happen more quickly, and developers require less training and knowledge transfer.

Let’s take a look at the typical workflows that Sencha developers use to build their desktop and mobile applications.

Sencha Cmd: Architectural Workflow

Whether you’re building an app with Ext JS or Sencha Touch the development workflow is essentially the same. However, some commands are needed more often than others.

When first starting a Sencha application, you will likely need the following commands:

  1. sencha generate workspace
  2. sencha generate app
  3. sencha cordova/phonegap init
  4. sencha upgrade and sencha app upgrade

sencha generate workspace

The first step in building any Sencha application is to create a workspace. The Sencha workspace is an environment in which multiple applications, libraries and frameworks (e.g. Touch and Ext JS) live side-by-side with their shared resources — helping Sencha Cmd understand the pages, frameworks, and the shared code used by the various parts of your application. This also enables Sencha Cmd to automate many common tasks.

To create a Sencha workspace:

sencha generate workspace ~/path/to/workspace

This command is normally only needed once, as the first step in the application development workflow.

sencha generate app

Once we have our workspace we should use Sencha Cmd to scaffold the initial application architecture. This will create an Ext JS or Touch application with default settings and all required dependencies:

sencha -sdk ~/path/to/extjs_or_touch_sdk generate app MyAppName ~/path/to/workspace/app

If you run this command from within an Ext JS or Touch SDK folder, you can drop the -sdk flag:

sencha generate app MyAppName ~/path/to/workspace/app

This command is also generally used once, at the very beginning of a project. However you might use this command more often if you create multiple apps inside the same workspace.

sencha cordova/phonegap init

Many of our customers who build mobile apps with Sencha Touch will also want to package their HTML5 application using Cordova or PhoneGap. Luckily, Sencha Cmd makes this really easy.

While the documentation and a previous post from Ross Gerbasi explain this process in more detail, integrating Cordova and PhoneGap in your Sencha app can be as simple as two steps:

    1. Create a config.xml file which contains important metadata for your application (see the API docs linked above for an example and more resources).
    2. Run the following:
sencha cordova init [appId]

or

sencha phonegap init [appId]

…where appId is the fully-qualified app ID from your platform’s developer portal (e.g. com.sencha.myapp).

Sencha Cmd will then automatically scaffold the relevant application pieces through its hooks with the Cordova and PhoneGap CLIs. Later in your development workflow, simply run sencha app build native and Sencha Cmd will automatically copy your bundled application resources into the configured projects for iOS, Android or other platforms.

This command is only needed once, at the point when you first integrate a Sencha Touch application with Cordova or PhoneGap.

Sencha Upgrades

Every so often you’ll need to upgrade your application to either (1) a newer version of Sencha Cmd, or (2) a newer version of the Ext JS or Touch SDK. Using the latest versions of the Sencha tools makes good sense, so you always have the latest bug fixes and performance improvements.

To upgrade Sencha Cmd to the latest version, we can use the sencha upgrade command:

sencha upgrade

Your terminal will automatically check for a newer version of Sencha Cmd and install it.

To upgrade an application to a newer version of Ext JS or Sencha Touch we need the sencha app upgrade command. Simply download the newest framework SDK and then run the following:

sencha app upgrade ~/path/to/new/SDK

However it’s possible that you may have customized a few important pieces of the Sencha application architecture, and you may not want the upgrade process to touch these bits. Luckily, Sencha Cmd has a few optional flags:

  • -noa (or –noappjs): Disable upgrade of app.js
  • -nob (or –nobackup): Disable backup of application before upgrade
  • -nof (or –noframework): Upgrade only the Sencha Cmd scaffolding and not the SDK

Sencha Cmd: Day-to-Day Development Workflow

In the day-to-day development of a Sencha app, developers often need to view their applications in the browser, edit code and test their apps in various environments. Therefore, most developers will use the following commands on a daily basis:

  1. sencha web start
  2. sencha app watch
  3. sencha app build

sencha web start

Now that we have an application started, we can immediately view it in our browser by launching a local web server. No need to configure IIS or Apache on your machine — Sencha Cmd has one built-in.

sencha web start

By default, Sencha Cmd will start a websever hosting our app at http://localhost:1841, so watch the terminal for any additional information.

sencha app watch

At this point, we can begin coding our app.

Having said that, we periodically need to tell Sencha Cmd about updates to our code, so the application knows:

  • where its dependencies are located
  • that classes have been added, removed, or renamed
  • that updated resources (like SASS) need to be recompiled

Running sencha app watch streamlines this process, so we don’t have to manually ask Sencha Cmd to refresh the application.

By running this command in your terminal:

sencha app watch

…Sencha Cmd will watch the filesystem for any changes. When it sees anything change that our application might depend on, Cmd will automatically regenerate our bootstrap files and/or recompile our CSS.

sencha app build

Once we have achieved some level of “completeness” in our application, we will want to use Sencha Cmd to gather the necessary resources and build a version of our app for testing or deployment.

The sencha app build command offers several build environments to accommodate the various deployment needs of your organization. Sencha Cmd also allows additional options for more granular control of the application build process.

The basic format is relatively simple:

sencha app build [options] [environment]

The build environments are:

  • testing: meant for QA prior to production. All JavaScript and CSS source files are bundled, but not minified, which makes it easier for debugging if needed
  • production: creates a production build that is normally hosted on a web server and serves multiple clients (devices). The build is offline-capable using HTML5 application cache and has built-in over-the-air delta updating feature
  • package*: creates a self-contained, re-distributable production build that normally runs from local file system without the need for a web server
  • native*: first generates a ‘package’ build, then packages it as a native application, ready to be deployed to native platforms

The commonly used build options are:

  • -c (or —clean): Remove previous build output prior to executing build
  • -d (or —destination): The directory to which the build output is written
  • -r* (or —run*): Enables automatically running builds with the native packager

*Note: this is a Sencha Touch-specific option

Therefore, a full application build command might look like:

sencha app build -c production

Advanced Cmd Workflow

Now that we’ve covered the important commands you’ll be using with Sencha Cmd, let’s take a moment to explore some more advanced pieces of the Sencha application architecture.

Understanding these areas becomes essential when you need to customize how Sencha Cmd views and builds your application.

build.xml

Understanding the application build process is integral to customizing how Sencha Cmd compiles your code.

Internally, the sencha app build command does basic validation and calls in to the Apache Ant build script found in “build.xml” at the root of the application. Specifically, it calls the “build” target of this script. This means the entire build process can be examined, extended and (if necessary) even modified.

configuration files

Sencha Cmd configuration properties are available to the build script but also drive many other features of Sencha Cmd (like the compiler).

In most cases, you can tell where each property comes from by its prefix:

  • app. — See “app.json” and “.sencha/app/sencha.cfg”.
  • workspace. — See “workspace.json” and “.sencha/workspace/sencha.cfg”.
  • framework. — See “cmd/sencha.cfg” in the Ext JS or Sencha Touch SDK.
  • cmd. — See “sencha.cfg” in the Sencha Cmd install folder.

build properties

There are many ways to configure build properties, the simplest being to edit one of the build properties files. To decide which file to edit, it is helpful to know the priority of each of these files and under what conditions they are loaded.

  • local.properties — If present, this file is loaded first and its properties have the highest priority. As this file is intended to be applied only locally it should not be committed to source control.
  • Sencha Cmd configuration properties — “sencha.cfg” in the Sencha Cmd install folder
  • .sencha/app/${build.environment}.properties — Setting properties in these files allows you to have different values for properties based on the type of build being run.
    • .sencha/app/native.properties
    • .sencha/app/package.properties
    • .sencha/app/production.properties
    • .sencha/app/testing.properties
  • .sencha/app/build.properties — These properties are loaded next and have lower priority over the build-environment-specific properties. These are properties that are used by all (or most) environments.
  • .sencha/app/defaults.properties — These properties are the last (default) values to load. This file is “owned” by Sencha Cmd and will be updated each release as new properties are added. This file serves as a reference for the defined set of build properties but should not be edited.

The only properties that have higher priority than local.properties are those passed in via the command line.

For example, you might know that Sencha Cmd uses YUI Compressor to compress your JavaScript code during a sencha app build native. But did you know that using Google Closure or UglifyJS instead is just as easy?

In ~/.sencha/app/defaults.properties you’ll see the following around line 150:

# enables / disables yui compression
build.compression.yui=0

# enables / disables closure compression
build.compression.closure=0

# enables / disables uglify compression
build.compression.ugilfy=0

Additionally, ~/.sencha/app/native.defaults.properties sets the YUI flag for you:

# enable yui compression
build.compression.yui=1

To use one of the other minification tools, simply set a different value for that property in a higher-level settings file (e.g. ~/.sencha/app/native.properties):

# disable yui compression
build.compression.yui=0

# enable closure compression
build.compression.closure=1

#or for UglifyJS
#build.compression.ugilfy=1

Cmd Packages

One of the newer features of Sencha Cmd is the concept of packages. Sencha packages are simply self-contained code or theme libraries intended for easy distribution and consumption. The general idea is similar to packages in npm, Ruby gems, and Python eggs — just specific to the Sencha ecosystem.

Sencha packages are a great way to share common user extensions or themes — and because many enterprises have built their own core libraries, Sencha packages are the easiest way to integrate that code across applications.

See the sencha generate package documentation for more details.

Conclusion

Sencha Cmd has cemented itself as the foundation of the Sencha application platform. From scaffolding a new project, to minifying and deploying your application to production, the Sencha Cmd lifecycle management features are essential to the enterprise development workflow.

By learning the basic commands Sencha Cmd uses to create and build applications, developers can expect the standard application architecture to smoothly integrate with their existing systems and deployment processes. Understanding the more advanced portions of the Sencha build process will allow developers to completely customize how Sencha Cmd compiles their code.

For more specific information about how Sencha Cmd works with the Ext JS and Sencha Touch frameworks, please read the guides available in each framework’s API docs.

Leave a Reply

Your email address will not be published. Required fields are marked *

Leave a Reply

Your email address will not be published. Required fields are marked *

coming soon

Something Awesome Is

COMING SOON!