I am having portlets in different pages inside liferay and trying to exchange data between these portlets using session attributes, but as per the documentation of liferay… things are not working with Vaadin portlets. Let me explain the problem here:
I have got two Vaadin portlets (different WARs) deployed in different pages of liferay. Inside the rendering method of Portlet A, I am setting an session attribute and trying to read this attribute in rendering method of Portlet B, which is not working. Any ideas?
Does anyone tried with Vaadin portlets to share session attributes across the different portlets on different pages?
How is it not working? Are you not seeing in portlet B the attributes you have set in Portlet A, or is there some other problem? Have you made this work between portlets from the same WAR, or between portlets from different WARs on the same page?
There are now three similar threads open on inter-portlet communication between pages, including
this one . I’m afraid I won’t get around to digging deeper into this at the moment, but maybe you and Juerg each have a piece of the puzzle.
One question to look into is the sessions (maybe even with a debugger) - there is a deep hierarchy of nested sessions in Liferay and another layer on top of that in Vaadin. Maybe the these attributes are not visible through the “top of the stack” session, and you need to get hold of a nested session to get the attributes.
Apologies, actually it was working fine. I was over looking at it and didn’t realized that it is working. As per the Liferay documentation… it was working fine with no issues.
However one basic question, how do we make these vaadin portlets not to get refreshed on Liferay portal? Every time when I click a button (or perform an action), the portlets are getting refreshed. Any approach to fix this?
As for the refresh, there should not be any extraneous refresh when clicking on buttons and otherwise normally interacting with the UI. There will, however, be a refresh when sending a portlet event or setting a shared render parameter.
I have written about this elsewhere on the forum. In short, there are four types of portlet requests (and corresponding responses): render, action, event and resource. Vaadin client-server communication normally takes place using resource requests, which do not trigger a page refresh, but based on the portlet 2.0 spec, only action and event responses permit directly sending portlet events or setting render parameters. This is due to the portlet page lifecycle, where first all portlets handle actions and events and then all are rendered. The other portlets on the same page would not see or react to the shared render parameter anyway before the render phase.
What Vaadin does if you try to call setSharedRenderParameter from another type of request is to trigger a new action request, which is internally “caught” and triggers the event or render parameter change the user asked for. This action, however, does trigger action processing and rendering for all the portlets on the page.
What you could try to do is to set the render parameter (or send portlet events) only when necessary, avoiding doing that if nothing changes.
Thank you for responding on this. I understand the page refresh thing happening because of “sending events”. However I would like to know, is it possible to make these sending events as Ajax calls? I don’t want the refresh on the event sending portlet, I want the refresh (or render) on the receiving event portlets. Is it possible?
I am not an expert in inter-portlet communication, but thinking about this a little:
It might be possible to send the events with some asynchronous background request, which might not be an Ajax request. However, this would trigger the “repainting” (from the point of view of the server) of the page where the target portlet of the related action is. If that page is the one the user is looking at, this could lead to the server and the client having an inconsistent view of the page contents if the results are not actually shown in the browser window. Whether this is a real problem or not might depend on your deployment scenario - I am not sure about this.
One option would be to send an action request in a “hidden” request to another “forwarding” portlet on another portal page (maybe with a fixed URL, using FriendlyURLMapper on Liferay), or directly to the target portlet. For that, you need to get an action URL from the target portlet. Maybe this target portlet could “publish” an action URL it has generated (after setEvent() on it, and setting some placeholder values for the relevant parameters to send back). This would not make some other browser elsewhere automatically refresh the page, though. Furthermore, something needs to trigger the generation of the target URL - maybe you need to first make e.g. a hidden render request to a minimal page with the target portlet to make it send your portlet the action URL. This would probably only be needed once in the lifetime of the (target) portlet and you can then re-use the URL, changing the parameters as needed.
In short, at least with the portal-independent APIs, this gets complicated but might be doable.
I am sorry… I couldn’t understand what exactly you are trying to say. May be it is problem with me, due to the lack of knowledge. Let me ask you one quick question… is the refresh on page, during sending events, is just happens on Vaadin portlets only? I seriously don’t understand why there is page refresh required here.
Let me give you a scenario where it causes issues for us… we have four portlets in a single page… and IPC happens between two portlets ( A and B ). The portlets (C& D) are showing static data and doesn’t worry about what happens on A & B portlets. If A sends an event to B, does it makes sense to refresh the whole page instead of refreshing B alone?
May be you need to look at Client Side Eventing and Server Side Eventing approaches in portals in general.
I am not sure about Vaadin as such.
However, I have the following advise for you…
One should write a portlet based on the page context or other portlets status. As you are aware Render method are called on all the portlets in that page, even if one portlet content changes.
This should be used for advantage rather than trying to fit in Ajax and complicating things though many alternate approaches.
Could you pl. let me know what is the extra render request effecting on the portlets C and D.
We at TejaSoft do code Audits to many companies, and see the following patterns… if it others let me know…
Many JSP used in render phase make direct JDBC calls… which kills the performance.
In Vadin context, during such render UI classes may be making JDBC calls
For Rendering to work, they would need many render parameters, which may not be available as current rendering is not happening due to previous action requests on C or D.
When action requests happen due to action happens in Portlets C, almost all the parameters are converted to render parameters so that rendering stage all the action values are available to make JDBC calls or view related decisions.
If you could let me know what is the side effect of render call on C and D, we could give some alternatives.
As this old topic popped up again, in case someone is reading the thread.
There is something of an “impedance mismatch” between Ajax use and the JSR-286 inter-portlet communication mechanisms: the latter are designed around a full page re-rendering, whereas this is precisely what Ajax frameworks try to avoid.
While the JSR-286 IPC mechanisms can be used with Vaadin, and often are the best approach when communicating between a Vaadin portlet and a non-Vaadin portlet, Vaadin does not get around the need to re-render. A model that is better suited for the Ajax world is one where only the affected UI components are updated, requiring a push or poll mechanism as well as some other approach to communication within the server.
One of the challenges for the server side communication when bypassing standard inter-portlet communication mechanisms is getting hold of the target (or source) portlet instance to get communication started.
The ICEFaces article uses a push mechanism (an alpha version of the ICEPush system that is also used by the Vaadin
ICEPush add-on ), and bypasses the standard inter-portlet communication mechanisms.
As for client side communication, Vaadin is a server side framework, and trying to communicate directly on the client side would probably lead to ugly hacks at best.