Pluto
  1. Pluto
  2. PLUTO-531

New PortletRequestStateService SPI to replace and extend most of the currrent incorrect used PropertyManager SPI and PortletURLProvider SPI

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: portlet container
    • Labels:
      None

      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.

        Activity

        Hide
        Ate Douma added a comment -

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

        Show
        Ate Douma added a comment - All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593

          People

          • Assignee:
            Ate Douma
            Reporter:
            Ate Douma
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development