[jira] Resolved: (PLUTO-531) New PortletRequestStateService SPI to replace and extend most of the currrent incorrect used PropertyManager SPI and PortletURLProvider SPI

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PLUTO-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ate Douma resolved PLUTO-531.
-----------------------------

    Resolution: Fixed

All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593

> New PortletRequestStateService SPI to replace and extend most of the currrent incorrect used PropertyManager SPI and PortletURLProvider SPI
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: PLUTO-531
>                 URL: https://issues.apache.org/jira/browse/PLUTO-531
>             Project: Pluto
>          Issue Type: Improvement
>          Components: portlet container
>    Affects Versions: 2.0.0
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.0.0
>
>
> Below copied (in part) from email discussion on the Pluto dev list, see also: http://www.nabble.com/More-required-Pluto-2.0-SPI-and-implementation-refactoring-issues-td21973310.html
> *** PortletURLProvider SPI
> This PortalCallbackService provided *factory* SPI really has too much responsibilities:
> - used as a *stateful* instance by:
>   - PortletContainerImpl doAction and fireEvent for generating a (Portal) redirect URL
>   - BaseURLImpl toString method for generating a PortletURL
> - used by PortletRequestImpl and ResourceURLImpl for accessing the *readonly* request scoped public render parameters
> - used by PortletRequestImpl both parsing and storing request dispatcher query string parameters
> - used by PortletContainerImpl as "back door" mechanism to store the final PortalURL after doAction/fireEvent
>   (inside the Pluto *Driver* PortalRequestContext, although it seems its not even actually used (anymore))
> As result, the SPI definition itself leads to tricky usage patterns which causes very difficult to maintain implementation code.
> I propose to trim down this interface to only provide the factory responsibility for new PortletURL generations, split off the readonly request state related methods to a new interface (see below), and drop the remaining (also no longer needed) methods.
> *** new: PortletRequestStateService SPI
> I propose this new SPI interface for providing readonly access to *all* types of request parameters and related state, including request properties (see below).
> Besides providing a pluggable solution for accessing all the request parameters (private, public, resource), it will also allow "fixing" the
> current implemented ResourceRequest.getResourceID() handling and the not yet implemented ResourceRequest.getCacheability().
> ResourceRequest.getResourceID() is currently implemented using a *hard coded* request parameter, which simply isn't usable as generic solution.
> *** PropertyManager SPI
> The current PropertyManager SPI also has too many responsibilities: it is used both for accessing the (readonly)
> PortletRequest properties (headers and cookies) as well as for storing new PortletResponse properties (headers, cookies and DOM elements for MARKUP_HEAD_ELEMENT contributions).
> Note: the current default implementation doesn't actually do anything when setting properties!
> I propose to move the readonly access for the current PortletRequest headers and cookies to the new PortletRequestStateService SPI (see above), and to provide a new SPI for handling the PortletResponse properties and all other PortletResponse state.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.