Hi Bruno,
Bruno Farache wrote:
Stefan, I've read that Portlet 2.0 will cover portlet events, do you
have any idea how is it going to work?
You are right. I recommend to read JSR 286, which is not final yet, but
there is a public early draft at jcp.org.
http://jcp.org/en/jsr/detail?id=286
What are the disadvantages of using session to accomplish portlet
communication?
There are several limitations if you use the session. Three of them:
1. The spec states that the communicating portlets have to be in the
same portlet application, which for instance makes it difficult to let
portlets of different vendors work together. Although some portal
vendors allow you to share state between different portlet apps.
2. A portlet, which reacts to a change in the session (actionPerformed
of the sender portlet) has to do this in the render phase. Hence it
cannot itself send an event to another portlet the same way due to the
life cycle in JSR 168 (the sequencing of render calls for portlets on a
portal page is undefined).
3. Using this mechanism makes it difficult to use portlet caching, which
stores the markup fragment of a render call, and may not call the
method for a while (thus the portlet will not receive a change "event").
The only option here is to disable portlet caching for the receiver
portlet, which may lead to poor performance.
I hope this helps,
Stefan
