Multi-page and Mixed Apps

Large Application Alternatives

Workspaces in Sencha Cmd describes the new workspace support
in Sencha Cmd that is designed specifically to facilitate large, multi-page applications.

This guide picks up where that guide left off and describes how to use lower-level
commands to perform some advanced build operations. These are primarily focused on creating
two scripts per page instead of the typical one ("all-classes.js") to improve caching as
users navigate between pages. While there are many variations on the ideas discussed here
that could be similarly implemented, this guide describes two approaches:

Putting all code common to multiple pages in a "common.js" file.

Putting all framework code needed by any page in a "common.js" file.

Further, since we are using lower-level commands in this guide, we use a custom application
folder structure to show how Sencha Cmd can be used to fit your own specific choices for
code organization.

This guide focuses primarily on Ext JS applications. Support for these techniques will be
available for Sencha Touch in future releases.

Custom Structure Application

To consider applications that do not have a workspace, lets assume that we have a two-page
application with the following folder structure:

This example could be extended to cover many more pages, which would make it harder to
follow the example commands. There are some features that only apply to applications with
three or more pages so we will expand the example to illustrate that usage.

Caching Shared Code

If users of the application tend to visit more than one page, it may be helpful to split
up the code such that common code is in a shared file while page-specific code is isolated
to a second script file.

In set operations terminology this is called a set "intersection". That is to say, we want to
take the files in the intersection of the two sets of files needed by each page and generate
a file with just those classes.

The first thing is to create the compile context and tell it the classpath for all of
the source code folders:

sencha compile -classpath=ext/src,common/src,page1/src,page2/src \

Then we use two page commands to include the source from each page as well as generate
the appropriate output pages in the build folder. Each page command produces a set
of files containing exactly the files needed by that page. These sets are given the names
page1 and page2. Finally, each generated output page will get an extra script tag
whose src attribute is "../common.js".

Alternative Strategy - Sharing A Framework Subset

A different way to partition shared code would be to isolate all of the framework code
needed by the application and produce a file similar to "ext-all.js" but only containing
those classes needed by some part of the application. This approach might load more of the
framework than needed by each page, but the benefits of the browser cache could easily
make up for this increase.

The difference between this command and the previous command is in how the common set is
calculated.

union -set page1,page2 and \
exclude -not -namespace Ext and \

In this case the union command is used to include all files used by either page. This
set is then reduced using the exclude command to remove all classes that are not in the
Ext namespace. This will leave only the framework code that is needed by either page in
the current set.

The remainder of the command above and below these two lines is the same as before.

Beyond Two Pages

Applications with more than two pages can be managed as an extension of a two-page
application as discussed above. Just add extra page commands (one for each page) and
extra set operations to produce the appropriate "all-classes.js" file for each page.

There are interesting possibilities for code sharing among the multiple pages. For
example, let's consider a five-page application structured in the same basic way.

It may be that the common set of files produced by the intersection of all pages is quite
small. This will force code that is not used by all pages out of "common.js" and into an
"all-classes.js" file for each page. One strategy for dealing with this is to manually
divide up similar pages and treat the application as multiple, independent, multipage
applications.

Another, simpler, way would be to use a "fuzzy intersection," that is an operation the
selects all classes used by a specified minimum number of pages. Here's an example:

Other than the three additional page commands as well as three stanzas of restore,
exclude and concat, the above command only changed from the original intersection in
this one way:

intersect -min=3 -set page1,page2,page3,page4,page5 and \

The -min switch activated the fuzzy intersection method. By default, intersect selects
classes used by 100% of the specified sets or, in this case, all 5 sets. With -min you
can override this threshold. By specifying -min=3 we are saying to include in the current
set any class used by at least 3 sets (or 60%).