There are all kinds of situations in web applications were you need to collect information from the user, and our Corporate Management Suite is no exception. Like many web apps, we used to pop open a new, smaller browser window for this purpose. It certainly got the job done, but there were all kinds of problems.

The most annoying of these were popup blockers. Not only do the new browsers ship with blockers installed and activated by default, but add-in toolbars from Yahoo! and Google closed our new windows as fast as we could open them.

We also had problems with this popup window confusing novice computer users. It completely took them out of the flow of the application and they sometimes became lost if they temporarily switched to another program or accidentally clicked somewhere else.

Finally, and maybe most frustrating to me, the darn thing just looked ugly. It was always the same size, didn’t move with the main browser, and taunted us with its operating system specific minimize and close buttons.

After a fair amount of internal debate we decided ditch the popup window and move to a Dynamic HTML modal dialog. It ended up being a fantastic decision and we haven’t looked back. Gone are the days of having the popup and main windows get out of sync. Our dynamic modal dialog is actually part of the HTML page now, and blocks you from clicking anywhere else while it’s open. It also resizes automatically based on screen real estate and adds scrollbars when needed.

We’ve since incorporated the code into our webpage, so you can go to our products page and click on the automated product tour button on the right to see an example of it in action. The code is an extension of Dojo’s modal dialog and I’d be happy to clean it up and provide it for download if there’s a demand.

Like many web-based software companies, a significant part of our frontend logic is dependent on JavaScript. This allows us to add all of the neat little animations and dynamic page updates that make web apps fun. It also dramatically increases the size of the JavaScript files that need to be downloaded.

Our approach in the past has been to just cache everything and forget about it. Unlike many public websites that have to operate under the assumption that the user’s cache will be empty, we can depend on a fairly high percentage of populated caches. And, because we have a single page application design, even if they don’t have the JavaScript cached, they only have to download the files once and they’ll be available the entire time the application is being used.

Our problem has actually been that pages are cached too much. We update our software fairly often, and most of the time these changes affect the JavaScript. When someone tries to use the app with outdated files in their cache all kinds of annoying blowups happen. Development was also a pain because we had to constantly keep clearing our browser cache to test new code. It wasn’t until recently, though, that we implemented a solution to these problems.

Step 1: Force Cache Reload After Upgrade
The most serious of caching problems was that people would have to manually clear their browser cache after we upgraded the application. This was solved by dynamically sticking the application version number into the JavaScript file’s querystring. Every time the app was upgraded the version number would change, as would the querystring. And, because the browser sees a new query string variable, it downloads the file from the server. The HTML being generated ended up looking like this:

<script type="text/javascript" src="js/dojo/dojo.js?redownloadToken=1.2.17"></script>

Step 2: Make the Developers’ Lives Easier
Developers are smart folks and can usually figure out when cache needs clearing. Just because they can, however, doesn’t mean they should have to. To remedy this problem we added a “development mode” to the app. When enabled, the redownloadToken above is changed from the application’s version number to a timestamp, effectively forcing a cache-free download on every page refresh. Even better, when development mode is enabled the app automatically uses the uncompressed dojo build for maximum debugability. Here’s the JSTL code we used:

<c:choose>
<c:when test="${development}">
<script type="text/javascript" src="<c:out value='${baseUrl}'/>/js/dojo/dojo.js.uncompressed.js?redownloadToken=<c:out value='${redownloadToken}'/>"></script>
</c:when>
<c:otherwise>
<script type="text/javascript" src="<c:out value='${baseUrl}'/>/js/dojo/dojo.js?redownloadToken=<c:out value='${redownloadToken}'/>"></script>
</c:otherwise>
</c:choose>


In the end we haven’t solved all caching problems, but our customers and developers are sure happier!

Part of what makes software development fun and interesting is working with cutting edge tools that enable developers to build fancier and (more importantly) better mouse traps. One such tool that we’ve come to embrace in working towards improving our application is the Dojo Framework. Full of features that create a rich and visually stunning AJAX application, version 0.4.1 of the Dojo Framework was recently released to the general public.

We here at Spider Strategies were looking forward to this new release to aid us in one particular problem that plagues all web applications, browser compatibility. In particular with Microsoft’s new IE7 being pushed out to clients automatically, we definitely wanted to see how Dojo and our performance management application, CMS, would fare against Microsoft’s latest browser. We also had an interest in see how well things worked when applied to Apple’s latest Safari 2.0.4 browser, for those inclined to work with Apple. As a side note, because we’re all developers, we do most of our development on Firefox (how could a web developer live without firebug?) and therefore are most interested in these other major browser platforms.

All developers know upgrades can be a double edged sword; fortunately nothing major broke and most of the problems we encountered were relatively minor and were due to some changes applied underneath the Dojo hood. This meant most of the changes we made were syntactic in nature. For example the way Dojo expressed coordinates in previous versions syntactically was the following :

[top, left]

In 0.4.1, this was changed to :

{ top: val, left: val }

A minor change for sure, but one that expresses the foundation for most of the problems we encountered. Other types of issues we encountered were due to some refactoring of the Dojo tree widgets, specifically the events associated with opening context menus and the ability to drag and drop tree nodes. In one instance the method of construction used to create our context menus had to change from using Dojo topics to using the dojo.event.connect system. While most problems were encountered were not specific to IE7, we did run into an issue with IE7 not being able to correctly calculate the height of content within a pane. However, this is somewhat a non issue as we plan to incorporate a custom dialog in the future.

Safari, on the other hand, proved to be a whole other beast entirely. Right from the start, there were problems immediately noticeable after logging into our application. In addition to several of the problems found common to other browsers, Safari went the extra distance in providing poor editor support for rich text editing and context menus. Ironically, Safari also provided the worst usable user interface (Apple is known for their sharp UIs) when compared to IE or Firefox. Many of the visual elements such as expandable boxes or cues provided during the dragging and dropping simply did not work, or just looked plain ugly. With the exception of the rich text editor, however, we were able to smooth out most of these issues. The rich text editor proved to be the single biggest challenge in getting Safari to work properly. The problem lies in the editor code of Safari 2.0.4, and while we implemented a workaround for this shortcoming, we hope the next version of Safari will be more kind.

Everyone expects to encounter problems to some degree when it comes to upgrades, but all things considered, the upgrade to Dojo 0.4.1 and IE7 went well with no major issues. More importantly, we now have full browser compatibility with “the big three” browsers, with most of the nuances in developing a cross browser web application transparent to the developer. This perhaps showcases one of the nicest benefits we’ve received after using the Dojo Framework to power our application.