[jira] Resolved: (PLUTO-532) New PortletResponseStateProvider SPI

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

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

Ate Douma resolved PLUTO-532.
-----------------------------

    Resolution: Fixed

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

> New PortletResponseStateProvider SPI
> ------------------------------------
>
>                 Key: PLUTO-532
>                 URL: https://issues.apache.org/jira/browse/PLUTO-532
>             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
> *** 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.

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