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

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0.0
• Fix Version/s: 2.0.0
• Component/s: portlet container
• Assignee: Ate Douma
• Reporter: Ate Douma
• Created: 19/Feb/09 16:17
• Updated: 14/Mar/09 03:25
• Resolved: 14/Mar/09 03:25

Description

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.