EXTJS - Basics of 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.

Follow these Steps :

1.  To generate a Workspace, use this command:
sencha -sdk /path/to/sdk generate workspace /path/to/workspace

eg:
sencha -sdk /Rajavk/senchaapi/ext4.2.2 generate workspace /Rajavk/mysenchworkspace

2. Next, generate app:
sencha -sdk /path/to/ExtJssdkFolder generate app MyAppName /path/to/workspace/MyAppFolder

Eg:
sencha -sdk /Rajavk/senchaapi/ext4.2.2 generate app MyFirstApp /Rajavk/mysenchworkspace/myfirstapp

3)  Go to project path and create sample controller through Sencha Cmd.
eg:
sencha generate controller MyControllerName


4)  Create Model using following command
eg:
sencha generate model ServerModel name:string

5)  Create sample view using following command (ExtJs Specific. Doesn’t work for touch )
eg:
sencha generate view Registration

6) Packaging Application:

Packaging decreases the loading time of your application. Here are the steps to package your app using Sencha Cmd.
Go to your project folder and execute the following command.

sencha app build [options] [environment]

eg:
for PROD, sencha app build production
 for QA,     sencha app build testing

7) Sencha Cmd: Daily 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:

sencha web start
sencha app watch
sencha app build

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

8) 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
eg:
sencha app build -c production

Once the build process has completed you can deploy the code found in the
/path/to/app/build/AppName/production folder to your production web server.

9) Generating a Custom Bootstrap:

Note. This process is handled automatically for applications generated by Sencha Cmd. If you are not using Sencha Cmd generated application, this section describes how to achieve the same results manually.

The primary use for the meta command is to create your own “bootstrap” file. This file gives the framework the same level of awareness of your application code that it has of the framework code itself.

The simplest way to manage your bootstrap file is to store it alongside your markup file. If that won’t work for you, read on to see how to manage relative paths. If you have your markup file in a source folder in your classpath, you need to tell the compiler to ignore the bootstrap file. Do this using the -ignore switch:

sencha compile -classpath=sdk/src,app -ignore bootstrap.js \

10) Enabling Wildcard Support in requires:
The end of "ext-debug.js" contains these two function calls:
eg:
Ext.ClassManager.addNameAlternateMappings({
    "Ext.draw.engine.ImageExporter": [],
    "Ext.layout.component.Auto": [],
    ...
});

Ext.ClassManager.addNameAliasMappings({
    "Ext.draw.engine.ImageExporter": [],
    "Ext.layout.component.Auto": [
        "layout.autocomponent"
    ],
    ...
});

It is the presence of these two pieces of metadata that allow wildcards to be used in requires statements. That is:
eg:
Ext.define('MyApp.App', {
    requires: [
        'Ext.grid.*'
    ],
    ...
});

All that is required to use wildcards in your own code is to provide the same bootstrap data for your app.

This command will produce a file that does just that:

sencha compile -classpath=app \
    meta -alias -out bootstrap.js and \
    meta -alt -append -out bootstrap.js

The above command line tells the compiler to read in the source in the app folder and generate two pieces of metadata. The second piece of metadata is written to the same output file as the first, but using the -append option to append to the file and not replace it.

Once you have the "bootstrap.js" file, change your page like so to add it to the x-bootstrap section:


   
       
           
               

               
           

           
       
   

   



11) The "bootstrap.js" file needs to be regenerated if you do any of the following:

Add a class
Remove a class
Change class aliases
Change class alternate names

Note. For applications generated by Sencha Cmd, this is handled as part of the build process of sencha app build. Alternatively, refreshing just the bootstrap instead of performing a full build is accomplished by the sencha app refresh command.

12) Exporting Loader Paths:

In large applications it can be helpful to organize your namespace using multiple source trees. In fact, Ext JS itself uses three source trees. This approach, however, has always presented problems for the dynamic loader requiring loader paths to be configured by hand to work around the issue. The compiler, however, has complete knowledge of class-to-file relationships given all of the source in the classpath. And the meta command can export that data for use in your application.

sencha compile -classpath=src1,src2,src3 \
    meta -alias -out bootstrap.js and \
    meta -alt -append -out bootstrap.js and \
    meta -loader -append -out bootstrap.js

Now the "bootstrap.js" file solves both problems. With this approach, the following things will also require you to rebuild "bootstrap.js":

Rename a file or folder
Reorganize the classpath
Reorganize the content of any of the source trees

13) Resolving Relative Paths with -base-path:
For many good reasons, paths need to be relative. Whenever you deal with relative paths, however, you need to solve the problem of where those relative paths are based.
eg:
sencha compile -classpath=src1,src2,src3 \
    meta -alias -out build/bootstrap.js and \
    meta -alt -append -out build/bootstrap.js and \
    meta -loader -append -base-path . -out build/bootstrap.js

14) Changing the Format:
By default, the meta command exports metadata in JSONP format using a function call wrapper appropriate for the type of metadata requested. If a different function call is desired or you want the data in JSON format, you can request this in the meta command.

In the example below, the aliases.json file will contain the alias data in JSON format. You cannot use -append in this case because JSON format requires a single, top-level object or array.

sencha compile -classpath=src1,src2,src3 \
    meta -alias -json -out aliases.json

And we customize the JSONP wrapping by supplying the function to call:

sencha compile -classpath=src1,src2,src3 \
    meta -alias -jsonp Foo.bar.doAliases -out aliases.js

15) Exporting Filenames:
The first difference with -filenames is that the default format is text. To produce JSON or JSONP, you must specify one of the -json or -jsonp options.

In the default mode of text, the filenames are written as lines of text, one filename per line. The following command will create "filenames.txt":

sencha compile -classpath=src1,src2,src3 \
    meta -filenames -out filenames.txt

Each line of the file can be decorated using the -tpl option. Because of the special characters needed for this example, we use a response file to hold the template. We put this in "template.txt", like this:



Then run the following command.
sencha compile -classpath=src1,src2,src3 \
    meta -filenames -tpl @template.txt -out filenames.txt

    We now have a chunk of markup that will “script-tag in” all of the files in their correct order.

For example:



16)Exporting Definitions:
The compiler normally reads metadata such as classes, namespaces and dependencies by parsing source code. In situations where this is hidden, for example, when obfuscating a library, the compiler will be unaware of any defined classes or their dependencies.

This form of metadata export can be used to provide the “symbols” for such libraries so that users can still compile their application using Sencha Cmd.
eg:
sencha compile -classpath=src1,src2,src3 \
    meta -definitions -out symbols.js

    The above creates a file that contains directives like this:
    // @define Foo.bar.Thing
// @require Ext.panel.Panel
// @uses Ext.layout.container.HBox

16) Few cmds for Sencha Touch:

sencha app upgrade Upgrades the specified application to the SDK at the current working directory.
sencha manifest create Generate a list of metadata for all classes found in the given directories
sencha fs difference Generates the deltas between two files in JSON format
sencha fs minify Minifies a JS file using either YUICompessor (default) or Closure Compiler and UglifyJS
sencha ant  Invoke Ant with helpful properties back to Sencha Command

Reference:
http://docs.sencha.com/cmd/5.x/advanced_cmd/cmd_metadata.html