Eventing in AJAX Portlets

Also known as client side eventing, it becomes a necessity when you have multiple AJAX portlets on a portal page, and since the whole page is never submitted, the JSR-286 Portlet Spec 2.0 eventing (server-side) is not any useful.

We implemented a new eventing extension, for client side events, in Open Source Portlet Container (OSPC), through which it made its way into WebSpace 10.0.

A developer, who is writing a Portlet Spec 2.0 compliant portlet, follows a pattern, certain conventions and implements specific interfaces. Then s/he creates a deployment descriptor, packages the portlet as a webapp and deploys it.
These are the steps that a typical 2.0 portlet development process will involve:

  • implement processAction method for generator- generating portlet calls setEvent method here, to generate an event
  • implement processEvent method for consumer - called by the portlet container on a portlet which consumes this event
  • implement render method (both) - renders content
  • create portlet.xml - defines elements for eventing

For client side eventing, the developer follows exact same steps, albeit on client-side, for example in the jsp.
In javascript, the developer implements a processAction and render functions for an event generating portlet. In processAction or render function, setEvent function is called by the developer. For event consumer portlet, javascript functions processEvent and render are implemented. Then the developer writes the deployment descriptor in the same way as defined in the Portlet 2.0 spec, except that the value-type of the event is identified by a special marker class com.sun.portlet.ClientEvent.

When portlets are deployed, portlet container reads the deployment descriptors. If portlet supports publishing event and if event's value type is the special marker class, then container automatically generates a javascript "EventQueue".
When portlet container reads the deployment descriptor for a portlet that supports processing the event and if event value type is the special marker class, then container automatically puts a call to the processEvent function of this portlet in the event queue of the generating portlet.

When generating portlet calls setEvent function, with the event payload as an argument, EventQueue of the generator in turn calls processEvent function of all the portlets which support processing this event.
Thus, wiring of the portlets is handled by container in the exact same way as it would have been done for server-side eventing, from the deployment descriptor. This happens transparently to the developer. 

Salient Features of this mechanism

  • Follows convention over configuration paradigm
  • Follows Portlet 2.0 spec defined pattern and conventions, but mimics it on the client side
  • Works like an extension of the specification
  • Eliminates developer learning curve
  • Auto wiring of portlets, transparent to the developer (handled by OSPC).
  • Arbitrary Event payload (similar as on server side)
  • Each generator portlet has its own namespaced event queue (auto generated)
  • Event generator portlet remains agnostic of the consumers.
  • Since the event queue of the generator portlet is populated by the container at runtime, no other code needs to change when new consumer portlets are deployed or added to the portal page.
  • Easily toolable by existing tools, because it follows the same conventions as the tools expect for server side eventing
  • Well defined name spacing and type definitions allows for deploy time checking
  • Use of W3C defined QName allows for standard name spacing
  • XMLPortletRequest (XPR) provides a wrapper over XMLHttpRequest (XHR), thus easing development further
In my next blog, we will take a closer look through an example. In the meantime, you can also take a look at this document as well as check out Deepak Gothe's blog on XPR.

If the front end AJAX portlets are based upon standards, it should be no problem to build the back-end in any language, theoretically.

If one wanted to start leveraging Eventing in AJAX portlets but use a back end of a standard web server and prototype a back end in shell or awk, where would one start?

Posted by David on December 02, 2009 at 02:58 AM PST #

First, eventing at front end here is not based upon standards because the standards don't define it. That's why this proprietary extension.
If your backend is not JSR-286 based Java Portlet container, then it might be advisable to follow widget/gadget type of framework. But if you mean to just use the AJAX portlets as front end, then the backend call can be made to any REST service which may be implemented in any scripting language.

Posted by Prashant Dighe on December 08, 2009 at 09:52 AM PST #

Post a Comment:
Comments are closed for this entry.

Prashant Dighe


« December 2016