rossenstoyanchev.org Blog

One thing Spring JavaScript does really well is enable rich client-side behavior in your application using best practices and without the need to learn JavaScript in-depth. This is great news but sooner or later you’ll run into a situation where you’ll wonder why a form is not submitting via Ajax, or perhaps is not submitting at all. It may sound scary but it’s actually not so hard to figure out your problem.

Use the Firebug add-on for Firefox. Click on the Net tab and see if any requests (either full refreshes or Ajax requests) are going out at all. If so check use the Net tab to see the actual response returned from the server. In most cases the above information is enough of a clue. On occasion though you’ll need to break out the debugger.

Using Firebug’s Script tab find the code you need, set a breakpoint, and re-execute the test or refresh the page. It’s quite easy to start stepping through although soon you’ll step into minified JavaScript. To get around that one option is modify your JavaScript includes. For example change dojo.js to dojo.js.uncompressed.js and Spring-Dojo.js to Spring-Dojo.js.uncompressed.js.

A second and more convenient option is to extract the uncompressed versions of the files (dojo.js.uncompressed.js and Spring-Dojo.js.uncompressed.js) from the Spring JavaScript jar, and save them under the root of your web application so that they become accessible as /dojo/dojo.js and /spring/Spring-Dojo.js respectively. After you do that debugging will get much easier because you’ll no longer have minified JavaScript. If using svn set svn:ignore on these directories and you’ll never have to worry about it again for your local environment.

To understand why this works consider the fact that Spring JavaScript bundles JavaScript files in a jar and serves them from the classpath with its ResourceServlet servlet translating the URL it gets to a package location. If you however place files on the same path under the root of your web application, those files will take precedence thus allowing you to shadow resources normally served from the classpath.

In the past I had looked at Dojo’s own unit tests and one thing that impressed me was the ability to double-click a local HTML file and have tests executed in my default browser.

Recently I began taking a closer look at the Dojo Objective Harness (DOH) and one of the first things I found out was that local tests could run in Konqueror but not in Firefox 3. Firebug showed errors such as the one below:

failed loading ../../dojo/./_firebug/firebug.js with error: [Exception… “Access to restricted URI denied” code: “1012″ nsresult: “0×805303f4 (NS_ERROR_DOM_BAD_URI)”

I looked around and found out that a security fix in Firefox 3 prevents loading files from sibling or parent sibling directories:

http://ejohn.org/blog/tightened-local-file-security
https://bugzilla.mozilla.org/show_bug.cgi?id=230606

The workaround for me was to put the dojotoolkit on a local server and load the tests through it. This works fine and allows me to debug tests using Firebug but it sure would be preferable to run these tests without a web server.

I just came back from the annual SpringOne Americas conference. As usual it was a privilege to meet and interact with colleagues, clients, and so many other attendees from the Spring community. This year I also had the pleasure of meeting Pete Higgins and Kris Zyp both from SitePen. Pete is the Dojo Toolkit lead and Kris who is also a Dojo developer has a ton of knowledge around using JSON for SOA interactions. He maintains the site http://www.json.com/.

It’s been almost a year since the new Spring MVC annotation-based programming model (a.k.a. @MVC) became final with Spring 2.5. A few months ago I put together an article summarizing its benefits. In my experience the flexibility of @MVC is easy to see by all who get to spend a little time with it. As an internal measure of acceptance among Spring Framework developers consider the fact that the traditional MVC controller hierarchy is going to be deprecated in Spring 3.0 (along with the JUnit 3.8 Spring test class hierarchy).

While there are no “bad” ways to use @MVC what has not yet emerged widely is a discussion on the more subtle nuances and “preferred” ways of using the annotations. For example consider this article, which puts together what the author feels are “best-of-breed” technologies in their particular niches: jQuery, Spring MVC, and XStream/Jettison. I am in no way picking on the author of the article. In fact I don’t even assume he isn’t aware of the points I’m about to make on how to improve the CarSelectorController.java with regards to the @MVC programming model.

For example the .html extension in the @RequestMapping URI can be dropped since it is ignored by the URI pattern match. In fact the entire URI paths can be dropped if the controller is used in conjunction with the ControllerClassNameHandlerMapping. I’d also lose the ModelAndView return value in favor of the simpler Model input parameter. Both methods would return void. With a few more changes like that it’s amazing how slim the methods will become.

As I already pointed out, the purpose of this post is not to pick on the above article. In fact Spring’s own PetClinic shows code that is very similar. This is understandable since the purpose of the PetClinic sample is to introduce new capabilities in the context of an existing body of knowledge.

With the upcoming deprecation of the traditional MVC controller hierarchy perhaps it is time to put the spotlight on more “opinionated” @MVC examples. The swf-booking-mvc sample aims to do that but its points about the @MVC model have not yet been widely perceived. This is part of my reasons why I plan on giving a talk at SpringOne Americas this December in which I plan to assemble and discuss a set of best practices surrounding the new @MVC programming model. Do you have any favorites you’d like to share?

If you’re like me using Ubuntu as your primary operating system you probably wait for a little bit before upgrading to a new version. I finally made the upgrade to Hardy Heron (Ubuntu 8.04) on my Lenovo T60. I have a few things to be very happy about:

• I was able to purge the binary-only ATI driver (fglrx) from my system. The open-source version (radeon) seems to work just fine with my Mobility x1400 graphics card and my 1680×1050 laptop LCD. I don’t get direct rendering, hence no cool desktop effects and no games but guess what? I can live with these limitations just fine. Instead I get much better dual-head support through xrandr, simple hassle-free installation, and a configuration that’s fully supported under Ubuntu.
• Suspend and hibernate work!!! This might be another good side effect from dropping the fglrx driver.
• Software version upgrades - skype 2 (hello video!), firefox 3, kde 3.5

Be sure to check here (important note about an upgrade freeze with 2.6.22-15):
https://help.ubuntu.com/community/HardyUpgrades

Here is a good reason to await Eclipse 3.4:
http://wiki.eclipse.org/Improve_multi-monitor_support

Finally got around to spending some time with Mylyn, the popular Eclipse plugin that helps you manage tasks and provides integration with task repositories like Bugzilla, JIRA, Trac, and others.

For me the CVS features built-in in Eclipse have always provided a high value day in day out. Integrating with bug tracking repositories is a further step in the same direction allows me to perform queries against JIRA for example to see issues I’m working without going to an external browser. This feature alone makes it worth having this plugin.

Taking that a step farther Mylyn provides intelligent, task sensitive, context switching. That is to say it hides or shows only what’s relevant to the task at hand in views such as the Project Explorer where you might normally browse through hundreds of files. Instead you see only the few files and methods you care about. This adds a certain kind of intelligence to Eclipse, the kind of intelligence I remember a long time when I used IntelliJ (oops, did I say that out loud?)

To learn more I recommend the Mylyn User Guide, which is actually not easy to find like anything else on eclipse.org:
http://wiki.eclipse.org/index.php/Mylyn_User_Guide

One oddity for Linux users… Using Alt+Click (mentioned a lot in Mik Kersten’s articles on IBM DevelopreWorks) just didn’t work for me. I kept trying without any luck. Finally I discovered Alt+Click is already mapped in GNOME desktop for moving windows and needs to be disabled. Also I had to hold down the Win key (Windows logo on it) together with Alt+Click and voila it worked! The User Guide has both of these documented.

I will be giving a talk at The Spring Experience comparing Spring Web Services to Apache Axis2 and CXF and expect the question about Java WS standards to come up. Why doesn’t Spring WS support Java standards? One way to look at this is to understand there are two types of Web Services: code-first and contract-first. Both use the same underlying mechanism (WSDL, SOAP, XML) but conceptually they are far apart. Code-first is really a form of remoting in which XML is merely a wire format. Contract-first on the other hand means much more focus on designing an effective contract independent of the implementation.

Consider standard XML schemas used in various industries such as Health Level 7 (HL7), Univeral Business Language (UBL), or even the Global Justice XML Data Model. These contracts are designed so that disparate business entities who need to exchange data can agree on common type definitions (sometimes that’s easier said than done). This involves a loosely coupled source and destination who need to have a stable contract and be able to evolve independent from each other.

Code-first on the other hand is easier to imagine in situations in which a source and a destination are closely related. For example a .NET client and Java service of the same application are really not that concerned with loose coupling but more with interoperability. What’s confusing is that while this is really a form of remoting it is also considered a Web Service. This terminology is fine but just because WSDL is involved in the exchange don’t expect that same WSDL to be an effective Web Service contract. That is to say one that will remain stable over time.

Going back to the question about Java Web Service standards. The standards are beginning to reflect the importance of the contract-first approach. For example JSR-181 defines annotations to influence the generation of WSDL from a Java endpoint. There is also the Provider interface that allows dealing with a message as a DOM tree. While this is an improvement over previous versions, contract-first remains a secondary topic. This is perhaps reflected in the fact JSR-181 defines the Start with Java development model as required while the Start with WSDL is left as optional.

Lastly to think that Spring Web Services is somehow against Java standards would be incorrect. They’re simply focused on different things. In fact Spring Web Services relies on a number of existing Java standards such as a simple servlet deployment model, JAXP, JAXB, XPath along with many other Java XML API’s and data binding toolkits.

For a good treatment of the Java Web Service standards I highly recommend Mark Hansen’s “SOA Using Java Web Services”. It is a fair, in-depth assessment that will give you a good idea about just how “simple” Web Services are. You can also read about some of his personal travails with the standards online in this blog entry.

The JSP custom tag library Displaytag is very good at one thing - rendering HTML tables including links for paging, sorting, and data export to different formats (CSV, Excel, XML). This is very useful for building JSP views but its value is diminished on pages with Ajax behavior because each of the generated page and sort links cause the entire page to be reloaded.

You can use AjaxTags - another JSP custom tag library to make a Displaytag table re-render itself through an AJAX request and that works fine but eventually you might outgrow the approach of wrapping JavaScript code with JSP custom tags and may want to gain further control of client-side behavior. Furthermore AjaxTags requires use of the Prototype JavaScript library, which may or may not suite your deployment scenario.

Actually adding AJAX behavior to a Displaytag table is not that difficult. The code shown below uses the Dojo toolkit but the demonstrated technique can be implemented with any of the other JavaScript toolkits that have remoting capabilities. This is what you need to:

1. Add a div tag around the Displaytag table.
2. Declare the JavaScript function shown below and pass the div id to it.

function ajaxifyDisplayTag(targetId) {

  var onclickHandler =
    function (event) {
      event.preventDefault();
      dojo.xhrGet({
        url: event.target.href,
        load: function(data){
            dojo.byId(targetId).innerHTML = data;
            dojo.parser.parse(dojo.byId(targetId));
            ajaxifyDisplayTag(targetId);
        },
        error: function(data){
            alert("HXR Error in ajaxifyDisplayTag" + data);
        },
    });
  };

  dojo.forEach(
    dojo.query('a', dojo.byId(targetId)),
      function(aTag) {
        console.debug('Set onclick handler for ' + aTag);
        dojo.connect(aTag, 'onclick', onclickHandler);
    }
  );
}

That’s it!

In short what the above function does is it finds every hyperlink within the specified div tag and connects a pre-defined handler to its onclick event. The handler prevents the actual event from taking place and instead fires an AJAX request to the same URL. The returned data is then used to replace the content of the target div tag. Since the returned HTML content is also a Displaytag table we need to invoke the above function on the returned HTML content to ensure its links are connected to our onclick handler.

Of course if your AJAX toolkit already has a data grid widget then you don’t need any of the above. Dojo users are about to get one very soon as part of Dojo the 1.0 release.

I’ve known about Beryl for some time but have been skeptical about installing it. 3D effects and other desktop eye candy is cool but it doesn’t trump productivity and stability.

It turned out I was wrong on both of these points. I finally made the move to Beryl and was surprised by the results, which are quite good. Most importantly I’ve since found lots of productivity-related features in Beryl that go beyond “eye candy”. Here is a short list:

1. Rotating among several desktop workspaces is plain cool but it is also very encouraging towards actually utilizing multiple desktop workspaces.
2. The animation effects on minimizing and closing windows are not to be estimated as a continuous source of geek-type inspiration.
3. Hitting F9 displays all active windows in the current workspace at the same time (like tiles) so you can pick the one you want. Hitting F8 does the same for active windows in all workspaces. Great stuff! When many windows are opened I hate cycling through!
4. Using the “Windows” (Super) key in combination with “h” toggles maximizing the window horizontally. I love this one: a life saver for wide-screen laptop users. Doing the same in combination with “v” toggles maximizing the window vertically.
5. Alt+F8 initiates resizing a window.

There are many other features I haven’t yet come to but I already feel much better about using a great desktop environment.

I am running a T60 Thinkpad with an ATI card (Radeon x1400). I use the proprietary fglrx driver because the free Radeon driver doesn’t support my card well. Given this my path to Beryl required using Xgl to get the 3D effects. You can find instructions by searching for “Beryl Xgl fglrx” or use this link.