However I do see a potential issue with cooperative portlets. Let’s say portletA has a “POST” form, and in its action phase it uses the property broker to call portletB. portletB could do a redirect to its own render URL, but wouldn’t the back-button in this scenario ultimately re-run portletA’s POST, and get the “Warning: Page Expired” experience?

I’m curious enough now that I’ll have to try it for myself, assuming you don’t know off-hand.

Thanks again, this is the best source of info I’ve found on the PRG pattern in portlets.

Is it the responsibility of the Portal to handle Redirect-after-Post automatically or it is up to the user to implement this in the processAction!?

Could you please give your opinion about

http://my.opera.com/behrangsa/blog/show.dml/498527#comments

and

http://my.opera.com/behrangsa/blog/show.dml/501538

?

Best regards,
Behi

Man, when are you going to write about the fundamental problems of JSF?

-Behi

I am badly waiting for your post on the wrong doings of JSF.

Best Wishes,
The Idempotent Guy (?)

I go into some details about when NOT to use it as well and which redirets to use for best effect. There are also things about error messages etc. that need some consideration as well as login forms.

I like the diagrams. Wish I’d thought of them too. I’ll link to this from my article though.

In Plumtree portlets, the portal stores all preferences, and also stores all links to key navigational elements in the portal application (such as preference pages). Navigation state is maintained by the portlet application itself; trying to stuff that nav data into a WSRP node, and maintain it through careful shepherding of what you send back in URL requests, is inherently a broken design.

The Plumtree model uses the concept of a “transformer” - literally, rewriting all links in the portlet application, including rewriting of javascript in the portlet application that forms links. This allows all link requests to be mediated by the portal automatically, without having to resort to recoding your application using an API. This mediation allows for pattern detection, which means you can detect when you’ve entered a “preference” page and therefore control what information you send to the portlet to use for rendering (i.e., user profile data, locale information, preferences and so on).

It also allows you to specify “gateway spaces”, or other URL patterns (read: multiple domains) that get rewritten. This lets you, for instance, mix content from multiple websites into a single portlet. Traditional IT views this as a secuirty risk; standard web software development views this as an absolute requirement. The classic example is that of an imageserver: static images are served from one domain, while dynamic content is served from another domain.

The URL rewriting feature also menas you can click on links in the portlet, but configure the portal to use in-place refresh (AJAX) to update the content, allowing you to update only a single portlet instead of many in a page refresh.

The standard model described by JSR-168 and WSRP 1.0 actually represents a complicated mix of producer and consumer on each end of the conversation. The correct design would have one end being the one and only producer, responsible for its own content, and the the portal end being a consumer, responsible for accurate rendering of the content, regardless of what button is clicked in the portlet application.