Eventing in AJAX Portlets
By Prashant Dighe on Nov 30, 2009
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.
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.
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