New PortletRequestStateService SPI to replace and extend most of the currrent
incorrect used PropertyManager SPI and PortletURLProvider SPI
-------------------------------------------------------------------------------------------------------------------------------------------
Key: PLUTO-531
URL: https://issues.apache.org/jira/browse/PLUTO-531
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
*** 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
