Custom dojo builds

Most of us would like to extend dojo widgets/make changes to dojo code and rebuld our widgets along with rest of the dojo code. Another reason would be to optimize load times for your dojo widgets. Given that the widgets are loaded lazily, you would want to load a compressed javascript dojo file which contains all the widgets you need in a compressed format.
Here is how you could go about doing a custom dojo build.

Download the dojo source from the dojo download site. 
 Unzip it, and you should find a util directory in there. Go to util/buildscripts/profiles .
Now you need to create your own profile file which you will give it as an input to the build process.
Lets call it foo.profile.js.
It could look something like this:

dependencies = {
    layers: [
        {
            name: "customdojo.js",
            dependencies: [
                "dijit.Dialog",
                "dijit.layout.ContentPane",
                "dijit.form.CheckBox",
                "dijit.form.ComboBox",
                "dijit.form.TextBox",
                "dijit.ProgressBar",
                "foo.widget.button",
                "foo.widget.table",
            ]
        }
    ],
    prefixes: [
        [ "dijit", "../dijit" ],
        [ "dojox", "../dojox" ],
        ["foo","../../web/javascript/foo"]
    ]
}

You would notice that the contents of this file are in json format. The first thing of importance is the attribute layers.name which defines the name of the output file that is produced as a part of the dojo build process. right now it is called as customdojo.js . This is followed by a list of widgets that you want to be a part of the customdojo.js file. You should notice a couple of custom widgets too as a part of the build.
Note that the prefixes define where to find the dojo widgets specified above. They point to the directories path relative to the "util" directory. Hennce, dijit resides in "../dijit" and my foo widgets reside in the "../../web/javascript/foo".
Now , the next thing is your build command.
After you have saved the above file as say foo.profile.js, go to one level above to util/buildscripts/ and run the "build.bat" or the "build.sh" file depending on which platform you are in.

If you are in linux you could do something like

build.sh profile=foo mini=true action=release version=x.x.x optimize=shrinksafe
 copyTests=false cssOptimize=comments

This should produce a "release" directory containing the customized dojo build. You could probably also gzip your resultant output as discussed in one of the blog entries earlier.
It would be much more convenient if we actually automated this whole build process with an ant task. I'll try to talk about that in my next blog entry.

Gzip javascript files

To gzip your javascript files, you can use the following ant task (you can add dependencies to your task as needed).
    <target name="gzipJavascript">
           
<gzip destfile="${destination-dir}/combined.js.gz" src="${path-to-your-js-file}/combined.js">
    </gzip>
</target>


and just invoke this from your ant task. Simple.

The output of the gzip process will now be stored in your prescribed directory. I usually store the un-gzipped ones and the gzipped ones in the same resultant directory.


The next thing you need to do is to make sure that your server can serve this gzipped content to the client. To do that, you will have to modify your server.xml appropriately (its location depends on which application server/web server) that you are using. I have been using jboss and hence i will describe what i did for jboss to be able to do it.

In your <jboss-install-location>/server/<domain>/deploy/jboss-web.deployer/server.xml

Put in the following code (the modified parts are in bold)

    <connector  port="8080" address="${jboss.bnd.address}"
         maxThreads="250" maxHttpHeaderSize="8192"
         emptySessionPath="true" protocol="HTTP/1.1"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         compression="on"
compressableMimeType="text/html,text/xml,text/css,text/javascript, application/x-javascript,application/javascript"
         connectionTimeout="20000" disableUploadTimeout="true" />

Now, the next step is to include the javascript file in your web page.





If i have web/javascript/appname/combined.js and web/javascript/appname/combined.js.gz as a result of my various stages of the build process, my javascript include will look something like this




        <script src="/web/javascript/appname/combined.js" type="text/javascript">
</script>     


Note that i specify the include normally as a "text/javascript" and i really dont specify the ".gz" suffix. The application server will analyze the incoming request and if the client can handle gzipped compressed files, then it will server the gzipped files. Else it will serve the normal file.


Since javascript load is blocking call, you should notice load times reduce drastically once you do this.you can also do this compression for other resources such as your html/css files too.

Javascript optimization for web applications

There are a number ways in which you can go about optimizing your web application. This is one of the places where you could probably find the holy grail.

Javascript download time is one of the major bottlenecks for web applications. Let me explain how i managed to reduce the download time of my incredibly huge and chunked javascript files to reduce load times.


While in development stages, it is nice and developer friendly to modularize javascript into various files and folders, the load time gets really ugly when you put the app into production. Given that most of us various web frameworks/libraries like dojo, jquery, ext-js etc.. which themselves load a number of javascript files in turn depending on their usage, it is better to optimize your javascript.
Combine your javascript


This should be pretty simple. You can start off by writing a simple java class which takes in a list of files as an argument. This would then read all the contents of the files and write them out into a simple file. You could call that "combined.js". You can call this as a task from your build script such as ant

Compress the resultant javascript (minification)

The combination process just produces a huge single bulky file. This will result in reducing the number of HTTP requests for javascript files but you would still have to deal with the size of the javascript file. There are number of tools which allow you to compress your javascript files. The compression basically minifies your code in the sense that all the formatting in the code (spacing/indenting even carriage returns) is removed out and variable names are "optimized". You cannot probably debug using this compressed version of javascript. I have been using YUI compressor in my project with much satisfaction. A number of resources are available on how to perform this and hence i am not going to blog about it here. You can probably find a good article on how to use the yui compressor in your ant task over here

GZip javascript

One of the final steps you could try to do is to gzip the resulting javascript. This really reduces the size of the javascript file that is to be downloaded to the client. I could manage to compress a 500 kb(approx) javascript file to about 90 kb. I will talk about gzip process in my next blog.

Since javascript resources are one of the main bottlenecks in an application loading process (along with heavy images), the above three steps should help you speed up your application load time.

Note that you could also apply above process for your CSS files if they start to become too large or even gzip your html files if they are large enough and take a while to download.

JSFOne happening

Never thought there would be a separate conference for JSF developers. This finally seems to be happening though. Got the news from the ever reliable aquarium blog about the JSF one conference. Biggies like Roger Kitain, Ed Burns, Kito Mann are supposed to be there. The event though seems to be taking place not in US but in Vienna from sept 4 - 6th. There has been a buzz forming around JSF 2.0 for now.. Hopefully there will be more light on it in this conference. To know more about the conference, you can go to the JSFone's website.