Partial Page Refresh with Portlet Events

General
1

I have two Vaadin (6.3.2) JSR286 portlets deployed from the same .war in Liferay (5.2.3). One portlet publishes an event to the other. This is done using the PortletApplicationContext2 to fire the event.


// Publisher Portlet
table.addListener(new Table.ValueChangeListener() {

            public void valueChange(ValueChangeEvent event) {
                Foo foo = (Foo) event.getProperty().getValue();
                    PortletApplicationContext2 ctx = (PortletApplicationContext2) getContext();
                    logger.info("Sending portlet event");
                    ctx.sendPortletEvent(getMainWindow(), new QName("http://www.this.org/events", "Foo"), foo);
            }
        });

This works as expected and the subscribing portlet receives the event. However, the entire page refreshes. Is it possible to just have the portlets themselves refresh?

I am new to portlet development and am trying to determine if this is the default behavior.

Appreciate any assistance.

2

Portlet events can only be sent from action or render requests. As user actions in a Vaadin application are sent to the server as resource requests, Vaadin has to create a new action request, reload the page with it and send the event from there.

Note that in many cases, the receiving portlet would need a page reload anyway to display the effects of the event.

There might also be a little information in
the book
, although not much on this specific topic.

A little background (from memory, I did not check the JSR-286 spec) for those interested on how different request types are currently used by Vaadin and to a large extent in JSR-286 portlet containers in general:

When a portal page is loaded, there are two main processing phases: action processing and rendering. First, all portlets receive any actions that are relevant to them. IIRC, this may happen in parallel. Then, when all portlets have processed all the relevant actions (possibly creating events, making changes to shared render parameters etc.), the render phase follows. Again, all portlets receive a render request, which the portal can choose to send in parallel or in sequence. The HTML fragments to show in the portlets are generated in the render phase.

When portlet events are sent, there is an additional event processing “phase” between the action and render phases. In practice, this may happen in parallel with the action processing phase or not, and events may be processed immediately when they are sent or queued, but all events to all portlets on the page are processed before the render phase.

In Vaadin applications, JSON requests from the client to the server (user actions) are handled as resource requests, which do not trigger this full reload. However, as there are no action processing and and render phases, there is no event processing either. Vaadin gets around this by creating a new action request that identifies the event to send (or shared render parameter change to make) and then telling the client side to reload the page with that action. This special action is intercepted before Vaadin calls PortletListeners, and processed by sending the event or making the render parameter change.

A render request for a Vaadin portlet just creates a small HTML fragment that loads the widgetset, which will then contact the server to ask for the content (in terms of Vaadin widgets) of the portlet.

3

Thank you for your response. It was very informative.

Is there a way to achieve IPC in an ajax manner by leveraging Vaadin’s “special action”?

4

For standard inter-portlet communication, I’m afraid that having a ResourceRequest as a starting point, it is necessary to create and open an action request. One can only send portlet events (through the standard API) with a StateAwareResponse, i.e. ActionResponse or EventResponse.

If the UI does not need to be updated, it might be possible to open that URL in the background, without refreshing the visible page. If only the contents of Vaadin portlets need to be refreshed, one could combine this technique e.g. with the
Refresher
. If only the sending portlet needs to be refreshed, just adding client code checking for UI updates after executing the action request in the background would be enough.

If someone has a better suggestion, please let me know.

5

Thank you Henri for your suggestion. I will see what I can come up with. :smiley:

6

Hi ,
long time from the last post. I am curious if there is already “standard” solution to use interportlet communication without refresh? of course with Vaadin portlets.

@Troy, have you been successful with some (maybe Refresher) workaround?

Guys if you can provide some samples I would really appreciate it.

Regards

7

Have you found a solution?

8

hi,
you should try refresher addon, I don’t know about another workaround.

Regards,
Matus

9

Refresher and ICEPush are the main options - the portlet lifecycle (in JSR-286) is pretty much built around a full render cycle after any event processing.

10

Hi Matus,

Sorry this response is so late. I was pulled off onto another project and haven’t checked the Vaadin forums in a while and wasn’t receiving updates to this post. :expressionless:

I did not find a solution and the Refresher plugin wasn’t what I was looking for.

One thing I was looking into was the Liferay client-site IPC feature (
http://www.liferay.com/community/wiki/-/wiki/Main/Client-side+Inter-Portlet+Communication
). However, as mentioned before, I was pulled off before I could get this to work. I also didn’t like the idea of being tied to a platform.

If you do get it to work, I would appreciate if you would share your solution. It’s still bugging me. :slight_smile:

Thanks,

11

There is now an add-on for Liferay client side IPC
here
.
Still platform specific, though - how portlet request processing phases work in JSR-286 is the issue for portable solutions.

12

Henri this is very informative and helpful. Thanks for your thoughts and response.