AJAX Portlet using DWR, Javascript Templates (JST)

After having developed several JSR 168 Portlets that were AJAX enabled, I thought it would be beneficial to look for a combination of tools and frameworks that would minimize the numerous problems that crop up in developing dynamic portlets. The benefit of using AJAX in portlets is obvious in that it allows for the ability to develop highly interactive portlets that do not require the entire page to be refresed for each update. Portal pages can get quite heavy with portlets and each page load (even with some form of caching in the backend) is wasteful when all that needs to be updated is the individual portlet.

The two main problems that I have faced in portlet development with AJAX were:

1. Finding a simple and powerful framework for AJAX to integrate javascript with backend java code.
2. Finding the best way to keep UI code cleanly separated from logic in javascript/java.

The first problem was really a matter of finding a solution to the mismatch Java code and then code required to integrate the client side using XMLHttp or XMLHttpRequest. Luckily, DWR has been in existence for a while and provides a neat solution for exposing backend Java methods as Javascript functions. A DWRServlet has to be bundled with the application that acts as the gateway between javascript and the POJOs on the server by way of configurations in a dwr.xml file or in the spring application context file. The DWRServlet produces the right javascript proxies so that client-side javascript can invoke methods using the same class and method names.
For example, if I have a method in the backend called AjaxHelper.callMethod() in java, an AjaxHelper.callMethod() function can be invoked in javascript with the latest parameter in the function being a javascript callback function to update the UI. Out of the box, different java objects are automatically converted to javascript objects. These include Date, JavaBeans, Lists, etc. Should any custom objects need to be converted, mechanisms exist to define those. As well, Java Exceptions can be converted and handled appropriately on the client side. One thing to note here is that the since the DWRServlet is bundled with the portlet, the portal framework has to allow for resources within the portlet war to be accessed under the /dwr subcontext. There may be a servlet filter that disallows this and as such a custom servlet filter might be required that allows access to this /dwr subcontext.

Now, the second part of any AJAX interactions involves updating the UI with something interesting. Traditionally this is done by manipulating the html elements directly from javascript. While this works for simple use cases such as updating a field or displaying a bit of text, it can get tricky in situations where more complex UI are being rendered such as data grids or dynamically updated forms. I had one portlet that had many views arranged as in a typical wizard in windows and the requirements were to be able to flip between them quickly. Although this is all doable just with javascript, it is rather painful to maintain, not to mention error-prone. A much better approach would be to have html snippets ready that could be updated and slipped in where appropriate. This also has drawbacks in that the data inside the html snippets (the actual values of form elements or data grids) have to be inserted and this again involves recreating the html string in javascript.

In order to solve this problem, I thought there might perhaps be a framework that allowed UI code to be represented just like in JSP or JSTL with an appropriate mechanism to inject the data at runtime and update the view. In my search I came across Trimpath Javascript Templates (JST) that does just that. It consists of functions that can take in templates and inject a javascript object called data into it. An example of this is as follows:

<table>
{for flight in flights}
<tr>
<td>${flight.number}</td>
</tr>
{/for}
</table>

The example above is rather simple in that it is displaying a table with one column outputting all the flight numbers in the flights list. The way to do this is to add our relevant model objects in a javascript object called data and process the template. The resulting HTML can then be inserted into the innerHTML of any div or other html element as appropriate.

The templates can be any strings and can be stored anywhere. The Trimpath people recommend that they be stored in the page inside hidden textarea elements for quick access. However, for portlet that will have many views and we do not want to load all this html on the initial load, we can store these templates in template files in the backend. The trick is to use DWR to retrieve these view templates and process them as required. An additional optimization that can be done here is to keep view templates cached in a javascript object for reuse.

As I’ve discussed above, these two frameworks can make for a powerful combination when developing highly interactive AJAX portlets that require clean and easy maintenance of UI and logic.

They can be found at:
DWR (link)
Trimpath JST(link)

Advertisements
AJAX Portlet using DWR, Javascript Templates (JST)

2 thoughts on “AJAX Portlet using DWR, Javascript Templates (JST)

  1. Michael says:

    Hi there, I was wondering if you had any success using trimpath and dwr together? I was actually just looking into this for a project I’m working on because it also will require multiple views to be updated in ajax. I have worked with both dwr and trimpath and after searching to see if they could be used together I found your post. I think it would save thousands of lines of javascript code.

    1. Hi Michael,
      Sorry for the late reply. I have indeed succeeded in using Trimpath JST with DWR. I had to do it in a portlet so I didn’t use Junction to manipulate my urls. Rather, I had to handcraft the mvc part of the javascript which would take an action and after determining a view, retrieve the view ‘template’ from the backend using DWR and cache it. Then it would inject the data through the template and then display on the page. The portlet I had developed using this is the Terminal Finder portlet at http://www.heathrowairport.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s