If you’re a web application developer you know that today’s market demands that web applications make use of Web 2.0 features and a rich user experience on the web is becoming more and more the “expectation” rather than a nice-to-have. The applications I’ve design recently adopt some powerful development frameworks like JBoss Seam and rich JSF component suites like RichFaces and ICEFaces and the results have been quite good. So what about portals? Do the same expectations exist? The answer is yes, and the question on many portlet developers’ minds is; “can I build rich Web 2.0 portlets, and if so, what are the tools at my disposal?”
Well, we know that for quite some time now we have been able to build portlets that are AJAXable (if that is really a word) using RichFaces, ICEFaces and other JSF component suites. What didn’t use to be doable (not easily anyway) was to have those rich portlets communicate with one another in a standard way that is portal agnostic. Some might say “who cares?” or “why would you want them to communicate in the first place?”
Imagine this; what if you had a series of rich Web 2.0 portlets that are nothing more than wrappers of one or more rich UI components that did something and did it quite well. For example, let’s say I decided to build a CMS client using a data table to display contents of a folder, a tree sructure to represent an Explorer like view of folders, and a preview panel to preview the selected document. Let’s say that I also wanted to build a search capability within this client. I can do all this in a web app. I can also do all this in a portlet. But wouldn’t it be nice (and powerful) if I was able to break each one of these UI components into different portlets that communicate with one another? Wouldn’t it be even nicer if each one of those portlets was a standalone portlet with a published interface describing how to make it do things? Let’s say you see the potential in this approach to building portlets, how can it be done?
JSR 286 defines how portlets should communicate, and Liferay portal is one of the leading open source portals that support JSR 286. For the sake of the point I’m trying to make in this post I’ll just mention that JSR 286 allows portlets to communicate using events that are triggered and consumed during the portlet lifecycle. So if I had a data table portlet that listened on a predefined event and expected certain arguments to tell it what to do, I can build it to be independant of who is using it. Just give it a list and it will display it. Using the same approach I can have a tree and a preview panel. Now here’s the kicker; I could then use another instance of the same data table portlet to display search results in another portal page or even on the same page. Now your portlets are highly reusable.
A visual representation could look something like this:
In this case My Folders is one portlet and Folder Contents is another. The same Folder Contents portlet could be used to show search results. This (I believe) is a powerful concept that can be used in a variety of creative and intuitive ways to provide a new breed of reusable portlets that are - in IoC terms - unaware of what they will be used for.