RE: Some thoughts on inter portlet communication through backing beans

[Marcio E Miranda]

Exactly,   The JSR 286 spec will address several issues that were lacking in the first one, inter portlet communication being a major one, but it is expected to be finished by the end of the year, and it will take some more time for portal vendors to be compliant, so I expect a general availability by the end of the first semester of 2007, maybe a little less.   In the meantime, we have to figure something out. Good that you find it a decent solution.   Marcio   From: Stan Silvert [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 14 de abril de 2006 21:13 To: MyFaces Discussion Subject: RE: Some thoughts on inter portlet communication through backing beans   Sounds like a decent solution.  Inteportlet communication will be defined by the next portlet spec but it will be quite some time before that is done.   Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert From: Marcio E Miranda [mailto:[EMAIL PROTECTED] Sent: Friday, April 14, 2006 6:07 PM To: MyFaces Discussion Subject: Some thoughts on inter portlet communication through backing beans   Hi,   I’d like to share some thoughts we had while developing a JSR 168 portlet application using JSF, specifically regarding inter portlet communication, and get some feedback from you.   The portlets we developed were highly coupled; an event in a portlet would trigger actions in different portlets, which might in turn trigger additional actions on additional portlets; so we needed some sort of inter portlet communication. Each portal vendor implements its own portlet event mechanism (at least most of them), but we didn’t want to be tied to any proprietary solution, so we had to think of something else.   Our solution was to enable inter portlet communication through backing beans. In our application, each portlet has a JSF view backed by a backing bean. The backing bean is created by JSF (managed bean) and stored in the session. An initializer class, implementing HttpSessionListener, creates what we called an EventBroker and stores it in the user session. Every backing bean interested in participating in the event mechanism must extend an abstract class called EventAwareBackingBean. This class implements HttpSessionBindingListener, so when the bean is bound to the session (done by JSF), the valueBound method will give it a reference to the Event broker and call the createListeners method. The createListeners method is an abstract method that should return a collection of Listeners that will be registered with the Event broker (each Listener will call some method in the backing bean).   When a backing bean wishes to fire an event, it should create an event implementing an interface (passing in the argument the source backing bean and a payload) and pass it to the Event broker. The broker will check all registered listeners and notify those which accept that event. When the listener is notified, it will call a method (defined in the listener) on the backing bean which has registered it.   We have tested this implementation on Liferay with My Faces and it is working fine. Do you see potential problems with this approach? Any feedback is appreciated.     ______________________ Marcio Miranda