Portal page to page navigation with IPC

[14年前 に Konrad - Schuler によって更新されました。]

Hi,

At first the following scenario.
I have a portalpage PAGE1 with the portlet PORTLET1 and the portalpage PAGE2 with the portlet PORTLET2. In my portlet PORTLET1 i have a button which sets a public render parameter. After a click on the button I want to navigate to the PAGE2 where the public render parameter will shown within the PORTLET2.

That the PORTLET2 can access to the public render parameter wich the PORTLET1 set, I solved like described in
http://blogs.sun.com/deepakg/entry/coordination_between_portlets_across_pages

But now I want to realise the navigation from the PAGE1 to PAGE2 when i click to the button within the PORTLET1.
I know that I can achieve this by setting "Link to Page" within the "Look and Feel" of the PORTLET1. But I want to implement it.

So for that i tried to send a redirect within the processAction method

public class MyPortlet extends javax.portlet.faces.GenericFacesPortlet {
...
public void processAction(ActionRequest actionRequest, ActionResponse actionResponse) throws PortletException, IOException {
super.processAction(actionRequest, actionResponse);
actionResponse.sendRedirect("http://localhost:8080/web/guest/privatepage2");
}
...
}

The redirect works fine if I don't set the render parameter and don't call
super.processAction(actionRequest, actionResponse);

But whe I do it, the redirect don't works because of the Exception
"Illegal to sendRedirect after setting window state, portlet mode, or render parameters".

I know this behavior is defined by the portlet spec., but how can I achieve the page to page navigation and the IPC?

Somebody know a solution for that?

(I am using Liferay 5.2.3 on JBoss 5.1 with the JBoss portletbridge 2.0.0.CR1 and JSF RI 1.2_13)

[14年前 に Konrad - Schuler によって更新されました。]

Nobody who can help me?

[14年前 に Konrad - Schuler によって更新されました。]

Hi,
when I use the sun portlet container (portlet.container.impl=sun) than the "coordination between portlets across pages" works well. But like I discribed in my previous post, I have a problem when I want to navigate from page to page.
When I use the liferay's internal portlet container (portlet.container.impl=internal) than the "coordination between portlets across pages" is not working, but the navigation from page to page I can achieve by setting the following

actionResponse.setProperty("referer", "http://localhost:8080/web/guest/privatepage2");

:-)
It's very pity that no container provides both features.
So I think I have to realise the communication of portlets by using the portlet session.

[14年前 に Konrad - Schuler によって更新されました。]

Sorry, but its not correct what I descibed in my last post.
There was something wrong when I tested it.

So I still have no solution for my problem, which I described above.
Please help!!!

[12年前 に Stian Sigvartsen によって更新されました。]

Not sure if you are still looking for a solution to this, but I'll have a go at providing one nevertheless, maybe it will benefit someone at least

I think it's nice to solve a problem like this with a solution that is more likely to be work with any JSR-286 compliant portal. The real challenge in doing this comes when you realise that the JSR-286 specification does not address page navigation at all. This makes sense because the specification is really just about portlets and not how they are presented. Any page URL generation feature is going to be proprietary to Liferay Portal. So with that in mind, IMHO, it would be sensible to encapsulate the page URL generation functionality in a separate Liferay only compatible portlet.

So I suggest you have two portlets. The first one, your PORTLET1, the second one I will call PAGE1NAVPORTLET.
The two will speak via JSR-286 eventing. The process flow would be as follows...

• PORTLET1 receives an action request
• PORTLET1 determines that it's job is done, so now it is sensible to allow the user to be sent to another page. i.e. PAGE2. So this can be communicated as an event. PORTLET1 publishes an event called something like "jobDone".
• PAGE1NAVPORTLET processes the "jobDone" event. And sets a render parameter on itself (not a public render parameter) to say it's ready to navigate the user.
• PAGE1NAVPORTLET render phase initiates and it checks the render parameter. If present, it generates a renderURL using the portlet API.

I think one neat thing about this solution is that it enables you to use "Link to Page" within the "Look and Feel" of the PAGE1NAVPORTLET to let Liferay know which page to navigate the user to. Hence benefiting from Liferay's internal mechanisms that prevent broken links and such.

The generated renderURL could be used when rendering a HTML button, or it may be automatically requested via JavaScript or another method of causing the URL to be requested.

The above provides a basic solution which can be expanded upon. For example, it would be useful to handle situations where multiple "jobDone" events are published, and there being a race condition as to which page the user will be sent to next as a consequence of this. After all, the order of events processing is undefined. Given this fact and also that you can only set one "Link to Page" per portlet instance in Liferay, it might be sensible to only use PAGE1NAVPORTLET to render next page URLs that are determined by other portlets through the eventing phase. The other portlets would be invisible in terms of rendering (though visible to a admin user so they can be configured with a "Link to Page"), but would process the "jobDone" event of PORTLET1 and others, and then publish via another named event, for example "appropriateNextURL". PAGE1NAVPORTLET would then scoop all these up and render a series of links in its render phase. Communicating these to the render phase could be done by using the portlet session object. If only one such event is processed by PAGE1NAVPORTLET, then it could generate JavaScript to automatically request that only URL. The render phase of PAGE1NAVPORTLET should clear the list from the portlet session once it has completed rendering so that the list is only generated in response to the current HTTP request.

Hope this is of some use, and I would be interested in hearing other's opinions on this topic.

-Stian