I have been doing custom builds of ExtJs for clients these days, who want to use only selected components from the toolkit, and therefore a trimmed down version of the ext-all.js and ext-all.css core javascript/css files for minimizing load times. Today itself, I built a custom version of the toolkit for a client who just wanted to use ComboBox (yes, only the ComboBox) from the toolkit, and wanted to have the smallest possible files with only the absolutely necessary dependencies for the ComboBox.

Ext 2.x provided an online toolkit builder to customize the toolkit build (still available here). Unfortunately the builder is not available for Ext 3.x (there are comments on Ext forums saying such a builder would be available for Ext 4.x). Brian Moeskau (one of the original creators of ExtJs and the man behind Ext Calendar) has written an excellent tutorial for doing a custom build of ExtJs here.

But that article also seems obsolete at the time this post was written. The article mentions the toolkit using Google code hosted project js-builder for building the toolkit. But ExtJs 3.x actually uses JSBuilder 2.0 from Sencha itself for building the toolkit (dont get confused between these 2, the first of these (js-builder) is a Google code hosted project that was used earlier by ExtJs for build process, but ExtJs 3.x uses Sencha’s own product JSBuilder for the build process).

Apart from the similarity in names, both the build tools are totally divergent. js-builder (Google code hosted) uses an Xml based configuration file for the build process, where JSBuilder (Sencha’s product) uses a JSON based configuration file (which is to be expected from Sencha, there are a javascript company, isn’t it).

The build process for JSBuilder (Sencha’s product) is pretty intuitive and all necessary information is well documented with the 2 text files that come with the build utility. Basically, it boils down to a single line for the build process:

java -jar JSBuilder.jar -p I:\ext-3.3.1\ext.jsb2 -d I:\ext-built

The all-important file for the build process is obviously the ext.jsb2, the JSON formatted configuration file. It’s pretty easy to understand and you can quickly get the hang of things by looking at the core ext.jsb2 file that comes with ExtJs downloads.

I have been using this file as the starting point for my custom builds. Basically, I copy that file and remove all non-required javascript/css files and packages that are not needed for the custom build. You need to be a bit careful with the dependencies, and ensure that all dependencies for your desired components are preserved e.g. for my ComboBox only build, I needed to keep ComboBox and all its base classes in the form package, JsonStore and all associated classes in the data package, and Ext core classes like Element etc. and some other utility classes from the toolkit. Layouts, Grids, TreePanels etc. were eliminated. As I said, you need to be a bit careful. In my case, I knew that the drop down list in the ComboBox is a DataView wrapped in a Layer, and therefore these classes were needed too.

In any case, it does not harm to be over selective. You can always eliminate any javascript/css files that you think are not required, build and test that your desired Components are working. If they aren’t, the javascript error stack traces would easily tell you what is missing, and you can go back, include the missing dependencies and re-build.

However, there’s one very important precaution to take for the custom build process. Eliminate all css files from the resources/css folder before doing your custom-build (only the css files in this folder and not in its sub-folders). Let me explain why.

Obviously, as you are picking selected components from the toolkit, you would always want to trim the css file for minimizing load times. In my case, I just needed roughly 1/5th of the total ExtJs css for supporting the ComboBox only custom build.

I eliminated all non-required css references from the build configuration file (ext.jsb2). To my surprise, the javascript files were building fine, but the css file ext-all.css had the same size as the original complete Ext css. I verified that my configuration file was correct, and that I was re-building it correctly.

On some investigation, I found the issue. The build configuration file has 3 main sections, one specifying the js files configuration and their dependencies, second for css configuration and their dependencies and the last one for the resources that are copied verbatim to the output folder (the License files, images, flash files etc. from the source).

Now JSBuilder parsed the configuration file, and executed actions in order (taking care of any dependencies). So, the js files were built first, then the css files, and finally the resources were copied to the destination.

Notice that the resources (including the entire resources folder from the source) were copied to the destination folder after css files were built. What happens is that the required css files specified in the .jsb2 configuration file are built in the output, producing the desired ext-all.css. But afterwards, it gets overwritten by the ext-all.css copied from the source folder as resources are being copied. So, essentially, you are left with the original ExtJs stylesheet and not your trimmed version of it.

The solution is also easy. Just remove all css files from “resources\css” folder from the source (including ext-all.css, ext-all-notheme.css, xtheme-blue.css, and xtheme-gray.css). But leave the css files in the sub-folders (structure, visuals sub-folders etc). So, now when you re-build, only the specified files would be assembled in ext-all.css which would not get overwritten subsequently while copying resources. It took me sometime to figure this out.