[
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.
