[PLUTO-64] PortalActionProvider usage requires a Portal to enforce PortletMode and/or WindowState changes earlier than intended

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: unspecified
• Fix Version/s: 1.0.1-rc2
• Component/s: portlet container
• Environment: Jetspeed-2-cvs-head
• Assignee: Unassigned
• Reporter: Ate Douma
• Created: 22/Sep/04 21:08
• Updated: 10/Dec/04 03:37
• Resolved: 30/Nov/04 22:44

Description

Pluto uses (a Portal supplied implementation of) PortalActionProvider in PortletContainerImpl.redirect() to notify the Portal of a new PortletMode and/or WindowState as set during ActionRequest handling.
These changes are meant to become effective during the next RenderRequest as specified by the portlet spec PLT.12.2.2.

But, although this notification is done just before the redirect is send to the client, these changes are really enforced upon the Portal during the (end of the) ActionRequest handling already.
Pluto namely relies on these changes to be put into effect immediately because the PortletURL used for the redirect is created using the current PortletMode and WindowState retrieved from the Portal.

For me, as Jetspeed-2 committer currently working on a rewrite of the PortletURL encoding and state management, this poses a problem to enforce an immutable navigational state (related to PortletMode and WindowState) for the duration of a PortletRequest.
AFAIK this is intended (although not required) as well as should be possible by the portlet spec.

The way it now is implemented in Pluto can very simply be modified though without any side-effect AFAIK, in such a way that the Portal is only notified of the upcoming PortletMode and WindowState changes but no longer required to put them into effect immediately.

If for the PortletURL created for the redirect the intended PortletMode and WindowState are used and not requested back from the Portal after PortalActionProvider is called, a Portal may ignore this notification and rely on the PortletURL to also have these changes encoded. Once the PortletURL is triggered these changes will become effective just as well and not earlier than intended.

Changing the usage of PortalActionProvider like this makes it more like a (required) listener but removes the requirement for the Portal to actually do something with it.

I already discussed this issue earlier on the developerslist:
http://nagoya.apache.org/eyebrowse/BrowseList?listId=261&by=thread&from=879931

I will attach a patch file implementing this proposed change (same as I send earlier to the list).

Regards,

Ate