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

["Nick Lothian (JIRA)" <pl...@jakarta.apache.org>]

     [ http://nagoya.apache.org/jira/browse/PLUTO-64?page=history ]
     
Nick Lothian resolved PLUTO-64:
-------------------------------

     Resolution: Fixed
    Fix Version: Current CVS

Patch Applied

> PortalActionProvider usage requires a Portal to enforce PortletMode and/or WindowState changes earlier than intended
> --------------------------------------------------------------------------------------------------------------------
>
>          Key: PLUTO-64
>          URL: http://nagoya.apache.org/jira/browse/PLUTO-64
>      Project: Pluto
>         Type: Bug
>   Components: portlet container
>     Versions: Current CVS
>  Environment: Jetspeed-2-cvs-head
>     Reporter: Ate Douma
>      Fix For: Current CVS
>  Attachments: patch.txt
>
> 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
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira