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.
