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