Archive for the ‘JavaScript’ Category

Shared Nothing Event-Loop Concurrency

Sunday, March 14th, 2010

Reading the above quote in a blog post about CommonJS/JSGI: The Emerging JavaScript Application Platform peeked my interest. What were they talking about? Digging around I found this really interesting talk by Ryan Dahl on event-loop concurrency.

The approach resonates with me for two reasons. One, as a Java developer I’ve seen a lot of improvements related to concurrency in the last few years. Yet fundamentally concurrency remains a significant issue. It’s neither simple to make programs safe, not is it simple to test for such conditions. Two, I once worked on a high-performing trading application that was built from the start as an event-driven system where services did not return values but posted messages on an internal message bus.

It’s interesting that JavaScript, which is now building up server-side support can approach concurrency differently.

Debugging With Spring JavaScript

Sunday, January 18th, 2009

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.

Adding Ajax Behavior to the Displaytag Library

Sunday, October 14th, 2007

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.