1. #1
    Sencha User
    Join Date
    Sep 2010
    Posts
    2
    Vote Rating
    1
    reanvdm is on a distinguished road

      1  

    Default Build for multi page apps

    Build for multi page apps


    The Sencha guide for structuring and building multi page apps
    at http://docs.sencha.com/extjs/5.0.0/c...cmd_multi.html
    is very compelling, but stops short of showing how one might go about customizing the build to make this sort of architecture a practical reality. The output of the compile commands in the example misses CSS compile steps, none of the additional dependencies are included in the page generated, no indication how to launch a "build" at level of a Workspace etc.

    It would be really useful to have a practical example showing how a complete combined build might be done.

    Use case for multiple "pages":
    - A large app with at least three distinct functional areas (admin, live data, mapping). Each of these have dozens of views, half as many controllers, models etc. So modularising code begins to be a concern.
    - A single app.js file forces users to download code they will not use. Custom classes for the admin component are 200kb minified and used by relatively few. The mapping component in turn makes use of a large 3d party library which users of the other components should not be forced to download.
    - Some clients require additional "custom" components/views which need to be kept logically separate, and should not be impacted by build changes to the main application. So additional "pages" need to be added ad hoc to individual builds - without impacting the core 3 modules.

    An ideal build (to optimise browser caching) in this scenario might
    1. Separate Ext framework code from application code - because the application code changes often. This means that changes to app code can be pushed without requiring users to reload framework code also. Ext framework code stays cached as far as possible.
    2. Share framework code between each of the sub pages - so users who move from one component to the other are not forced to download a new build of the framework. The file size benefit of a custom framework build for each "page" is outweighed by the cost to users who move between pages.
    3. CSS is shared between all three "pages" for same reasons as 2. above
    4. Allow each "page" to include only its own custom classes, as well as any third party code that may be required (e.g. mapping libraries etc)

    On the Sencha guide that I linked to at top of this post, there is an example that does exactly this (though only for the js compile) - under the heading "Alternative Strategy - Sharing A Framework Subset". Unfortunately, trying this with Ext 4.2.0.663 and CMD 4.0.4.84 results in JS errors (Ext not defined).

    Any advice on how I get the job done?

  2. #2
    Sencha User
    Join Date
    Sep 2010
    Posts
    2
    Vote Rating
    1
    reanvdm is on a distinguished road

      0  

    Default Build for multi page apps

    Build for multi page apps


    Just to add - right now we're already doing this the legacy way: running SDK 2.0 build against jsb3 files which are manually updated to include all the classes we need in each case. Was hoping that, with Ext4.2 and the Neptune template using SASS we could move away from 'manual' builds, include css in build step etc.

    I further tested the "split build" feature as discussed here:
    http://www.sencha.com/forum/showthre...pile-js-target
    and after hacking to get it to actually do a split build found my framework.js file was 1.5mb - bigger than ext-all.js . It was also not included in the index page generated. (Test case was a blank single page app generated by Sencha cmd.)

  3. #3
    Sencha Premium Member
    Join Date
    Apr 2012
    Posts
    11
    Vote Rating
    1
    davidmarginian is on a distinguished road

      0  

    Default


    I have a similar use case. I want to be able to generate a separate file for all of my application classes that is not compressed so that it can be modified where it is deployed. I messed around with the split build stuff and ended up hacking js-impl.xml to get it to work. But I am also having an issue with the size of the framework.js file being larger than ext-all.js. There is no point to a split build if you cannot generate a framework.js file that only includes the framework classes that are actually being used. The main issue seems to be that whatever gets compiled gets generated via concat. There are no options to inlclude/exclude certain namespaces/classes etc. via concat so it appears we are stuck. Did you ever find a solution to this? Can anyone from Sencha comment on this?

  4. #4
    Sencha Premium Member
    Join Date
    Apr 2012
    Posts
    11
    Vote Rating
    1
    davidmarginian is on a distinguished road

      0  

    Default


    I figured this out by studying the documentation in more depth. Here it is:

    Code:
    # Build a set containing everything, the entire application and the used framework.
    restore
        page
    and
    save
        entireApp
    and
    # Build a set containing the entire framework.
    union
        -tag=package-sencha-core,framework
    and
    save
        entireFramework
    and
    # Output just the used framework code, it is the intersection of entireApp and entireFramework.
    intersect
        -set=entireApp,entireFramework
    and
    ${build.optimize}
    and
    concat
        ${build.compression}
        -out=${build.framework.file}
        ${build.concat.options}
    # Output just the application code.
    and
    restore
         page
    and
    exclude
          -tag=framework,package-sencha-core
    and
    ${build.optimize}
    and
    concat
         -out=${build.classes.file}
          ${build.concat.options}
          -b
    This will build a file for your application code that is not compressed and beautified and a file for only the framework classes you are using. I added this to the CDATA section of the -compile-js target in js-impl.xml

Thread Participants: 1