Proposal for 3.0 IMPL: BridgeRequestScope must not be restored when a
supported-public-render-parameter value changes
---------------------------------------------------------------------------------------------------------------------
Key: PORTLETBRIDGE-209
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-209
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman
This is a proposal to add the following language to Section 5.3 of the Spec
which discusses Public Render Parameters:
If the current portlet is participating in Inter-Portlet Communication (IPC)
via supported-public-render-parameter entries in portlet.xml and any of the
values have changed, then the BridgeRequestScope must not be restored.
I discovered this use case while testing the Public Render Parameters example
portlet at portletfaces.org:
http://www.portletfaces.org/portletfaces-bridge/examples/jsf2-ipc-pub-render-params
I think that this one is hard to understand at first, so perhaps the following
Use Case (taken from the aforementioned example portlet) will help describe the
problem:
1. Customers portlet and Bookings portlet are placed on the same portal page
2. User selects a customer from the Customers portlet, which invokes the
portlet ACTION_PHASE and the bridge processes "selectedCustomerId" as an
OUTGOING Public Render Parameter
3. Bookings portlet undergoes the RENDER_PHASE of the portlet lifecycle, and
the bridge processes "selectedCustomerId" as an INCOMING Public Render
Parameter. Bookings portlet updates its UI to show booking details for the
selected customer.
4. User changes a form field value (like first name or last name) in the
Bookings portlet and clicks Submit which invokes the portlet ACTION_PHASE for
the Bookings portlet. Consequently a new BridgeRequestScope is created for the
Bookings portlet. Customers portlet undergoes the RENDER_PHASE of the portlet
lifecycle and updates its UI accordingly.
5. User selects a DIFFERENT customer from the Customers portlet, which again
invokes the ACTION_PHASE and the bridge processes "selectedCustomerId" as an
OUTGOING Public Render Parameter
6. Bookings portlet again undergoes the RENDER_PHASE of the portlet lifecycle.
BUT AT THIS POINT the BridgeRequestScope created in Step#4 MUST NOT BE
RESTORED. If it were restored, then the bridge would not Lifecycle.execute(),
and skip directly to the RENDER_RESPONSE phase. That means that the INCOMING
Public Render Parameters handled by the PhaseListener in Spec Section 5.3.2
would get skipped, and the new selectedCustomerId would not be processed. By
not restoring, Lifecycle.execute() is permitted to happen, and the INCOMING
Public Render Parameters are processed accordingly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
