Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.0.0
-
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).
- new: PortletResponseStateProvider SPI
-
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.