Pluto
  1. Pluto
  2. PLUTO-532

New PortletResponseStateProvider 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

          • new: PortletResponseStateProvider SPI
            The current PortletResponse (and derivate) implementations "write" the response state directly to the portal provided servlet response, or use the above described PropertyManager SPI (see: PLUTO-531)
            For the generated content output, this solution assumes (requires) that the portal provided servlet response properly deals with
            the required buffering, content type, etc. handling, but this is not appropriately captured in a SPI contract.
            In addition, essential JSR-286 features like CacheControl, PortletWindow title setting nextPossiblePortletModes, etc. are not yet implemented or in an unexpected way (RenderResponse.setTitle using PortalCallback.setTitle).

      In my view, all these response "state" parameters need to be dealt with as a single set as the aggregating portal will have to deal
      with then as a a single set anyway. For example, Once response caching is properly implemented, all these response state parameters need
      to be cached as one set. For that, one single SPI should be used instead of requiring a generic servlet response wrapper
      implementation by the Portal without any formal contract as well as having to "merge" with some other SPI callback method results too.

      I propose adding a new PortletResponseStateProvider SPI to take over the set* methods of the current PropertyManager SPI
      as well as for storing response content (and related attributes like contentType), PortletWindow title, nextPossiblePortletModes and the CacheControl. All PortletResponse (and dispatched Servletresponse) methods dealing with writing content state should delegate to this new SPI.
      The aggregating portal then can retrieve and process the resulting response state as a single entity after the portlet invocation is completed.

        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:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development