Using portlets, you are able to develop tiny little applications that are suitable for a small subset of the actual functionality your customer wants. By combining them, they make it possible to create powerful but still modular applications that meet exactly the use cases your customer needs help with.

In theory.

In practice, you will be faced with a problem that is obviously a blind spot of the portlet definition (at least, the “old” JSR-186): how to communicate between portlets. The ability to mix-and-match portlets is key to a truly pluggable application formed of portlets.

To solve the communication problem, we have developed a solution much like the one developed by the folks at liferay, but a bit more tuned and optimized for a fully pluggable solution.

Portlet Services and Invokers

Our implementation follows a simple pattern: Portlets are able to promote services to a page-central instance and can include interaction elements that are used to invoke services that match certain criteria:

• the type of object the service must be able to handle
• the type of operation the service offers

Promoting a service to other portlets includes:

• specifying what type of operation (CREATE/READ/UPDATE/DELETE) is offered
• a text telling the user what happens when invoking the service
• the function that should get called on service activation

Using these simple building blocks we can offer users a list of actions that are available for a specific object:

Completely discoupled

The major advantage of our solution is that we do not hard-wire which portlets offers what to other portlets. All you have to do is insert a service invoker into the UI and the framework does the work for you. All people working on the project can work in parallel, the communication overhead is minimal. All the developers must do is offering a portlets services using the framework and give services a name that speaks.

This makes turns our product into a completely customizable platform that fits exactly our users’s needs.

Maximum flexibility

The framework makes splitting up responsibilities between portlets easy and puzzling just the right application for the job together possible. After adding a new portlet to a page, all service menus are automatically updated to offer new services that may have been added by the new portlet.

A generated service menu

Service menu for a different set of portlets

What you see in these screenshots is that depending on which portlets are available, the portlet will offer different actions for an object (for Screenshot 2, the “Ping” portlet was added). All information about which services are available is calculated client-side and for the current setup. Adding a new portlet will add its services to the actions list. The text that appears inside the menu is set by the portlet offering the service.

Invoking services is not limited to the context menus. We also use buttons for services that enable the creation of new items.

Impacts on portlet design

All this makes it easy to develop portlets that are designed to fulfill small tasks the right way. Reusability of portlets is massively increased. And on top of all this you get a consistent usage pattern that your customers will be familiar with when you are adding more functionality.

This is the third article in my mini-series about developing highly ajaxified portlets. In this blog, you can also find articles about:

• Using YUI loader for your own javascript modules
  
• Portlet namespaces and javascript

In my next post in this series, i will give a little insight into how we use metadata generated by our server to make creating a fully ajax portlet a breeze. Meanwhile, check out our posts about testing our Ajax frontends using Selenium and the YUI Test framework.