When using the Dojo Toolkit in an application, I setup the application so that one of three different configurations can be used. There is a production, an uncompressed, and a debug configuration. Each of these configurations can be used to load the Dojo Toolkit and any custom javascript.
The production configuration uses the output of the Dojo build. The javascript files are minified and combined into a single file. This is the default configuration and used by default. Since this code is minified, it is very hard to debug.
As part of the Dojo build process, a second set of files are created. These files end in .uncompressed.js. The uncompressed configuration uses these files. It is still a single file for javascript and loads fast, but the javascript code is human readable. This makes it easier to step through code using a browser's javascript debugger. While it is easy to debug, it still requires a build cycle to deploy changes.
The third configuration is the debug configuration. This configuration points directly at the source code and does not use the build process. This is noticeably slower when loading pages because the browser is loading many files but this configuration doesn't require a build to see changes made to source.
When an application is deployed, the debug configuration is not made available. The production configuration is the default and having the uncompressed available allows a developer to troubleshoot a problem on an end user's machine. The debug configuration is valuable when developing a significant piece of javascript and you do not want to be continually building to see your changes.
Implementation
I use a query string parameter to specify a different configuration. This requires server side code to interpret the query string value and swap out a configuration. You may find it useful for the server code to place the value in the session. Doing so allows yout to navigate to different pages without continuing to modify the query string.
A simplified folder structure is:
static
dojo-release
dojo
dojo.js
dojo.js.uncompressed.js
myDojoCode
custom-dojo.js
custom-dojo.js.uncompressed.js
dojo-source*
dojo
dojo.js
myDojoCode
[a bunch of custom javascript files]
* only exists on development machines
The HTML output when using the production configuration would look something like:
<script type="text/javascript" src="/static/dojo-release/dojo/dojo.js" djConfig="parseOnLoad: false"></script>
<script type="text/javascript" src="/static/dojo-release/myDojoCode/custom-dojo.js"></script>
The uncompressed like this:
<script type="text/javascript" src="/static/dojo-release/dojo/dojo.js.uncompressed.js" djConfig="parseOnLoad: false"></script>
<script type="text/javascript" src="/static/dojo-release/myDojoCode/ custom-dojo.js.uncompressed.js"></script>
The debug like this:
<script type="text/javascript" src="/static/dojo-source/dojo/dojo.js" djConfig="parseOnLoad: false, debug: 'true'"></script>
dojo.js is the core dojo kernal and custom-dojo.js contains the auxiliary javascript code in a single file. The source of this code exists in multiple files in the source folder. In the debug configuration, we do not include an all encompassing file because we want Dojo to load the individual source files.
Monday, March 5, 2012
Wednesday, February 29, 2012
Welcome to the Swinging Code Blog
My name is Craig Swing. I write code for a living and this is my blog.
My primary goal for 2012 is to increase my professional web presence. For the first time that I remember, LinkedIn says that my profile is 100% complete. And now I start my development blog.
The goal of this blog is to improve my technical writing, share resources, architectural ideas, and coding examples that I find useful. Most of my current technical interests include the Java open source community, including Hibernate, Spring and the Dojo Toolkit, but I also have experience using the Microsoft stack as well.
As part of launching this blog, I am also launching an open source project called evince. The evince framework will be a collection of code that I have found useful in building web applications on a Java open source stack. The evince framework will be licensed using The Apache Software License, 2.0. The code will be hosted on GitHub and the feature set will include the following:
My primary goal for 2012 is to increase my professional web presence. For the first time that I remember, LinkedIn says that my profile is 100% complete. And now I start my development blog.
The goal of this blog is to improve my technical writing, share resources, architectural ideas, and coding examples that I find useful. Most of my current technical interests include the Java open source community, including Hibernate, Spring and the Dojo Toolkit, but I also have experience using the Microsoft stack as well.
As part of launching this blog, I am also launching an open source project called evince. The evince framework will be a collection of code that I have found useful in building web applications on a Java open source stack. The evince framework will be licensed using The Apache Software License, 2.0. The code will be hosted on GitHub and the feature set will include the following:
- A Dojo view implementation for Spring Web MVC
- A JSON serialization engine to support serializing a collection POJOs into a json structure that can be used to instantiate a Dojo data store.
- Support for creating a "stored procedure" in a java class using the JPA Criteria API.
Subscribe to:
Posts (Atom)