jsfportletbridge
  1. jsfportletbridge
  2. JSFPORTLETBRIDGE-30

jsf-portlet needs to keep track of request scoped information to use in jsf lifecycles

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.2.3
    • Component/s: implementation
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Sun

    • Issuezilla Id:
      30

      Description

      JSF webapps follow the JSF lifecycle (decode, validate, update, apply actions
      and render phases). In these webapps, the same request is used for all the
      phases. So, any request scoped information will be available for all the phases.
      However, when this webapp is run as a portlet-app using the jsf-portlet bridge
      in Portal environment, the portlet container dispatches two requests.
      first for - decode, validate, update, apply actions phase
      second - render phase

      As a result, any request scoped information (objects, backing beans etc) that is
      used in the decode, validate, update, apply actions phase is not available in
      the render phase (because this is a new request)

      A simple example would be 'alerts'

      • User clicks on a button (associated with a action handler)on the UI
      • Form is submitted, goes through the decode, validate, update phases of JSF
      • Action handler is invoked in the 'apply actions' phase
      • The handler performs action and sets a message/alert to be displayed
      • This alert could be say, obtained via a value-binding of a backing bean
        (request scope, already created in the above phases)
      • Now, in the 'render phase', a new request is used by the portlet container and
        so new backing bean obj. is created thus losing all the information set previously.
      • The page does not display any alerts/messages

      One of the main intentions of jsf-portlet bridge is to easily convert JSF
      webapps to portlets. This is a big hinderance in that direction.

        Activity

        Hide
        dgothe added a comment -

        This can be done by using ExternalContext's RequestMap backed by Session and the
        session should be cleared on each action request. Also in order to provide the
        parameters set in action cycle to render cycle the parameters in action should
        be set as render parameters. In order to enable this functionality the jsf
        portlet must have init parameter in its portlet.xml as follows
        <init-param>
        <name>com.sun.faces.portlet.SAVE_REQUEST_SCOPE</name>
        <value>true</value>
        </init-param>

        Show
        dgothe added a comment - This can be done by using ExternalContext's RequestMap backed by Session and the session should be cleared on each action request. Also in order to provide the parameters set in action cycle to render cycle the parameters in action should be set as render parameters. In order to enable this functionality the jsf portlet must have init parameter in its portlet.xml as follows <init-param> <name>com.sun.faces.portlet.SAVE_REQUEST_SCOPE</name> <value>true</value> </init-param>
        Hide
        dgothe added a comment -

        Created an attachment (id=26)
        CRT for v1.1

        Show
        dgothe added a comment - Created an attachment (id=26) CRT for v1.1
        Hide
        dgothe added a comment -

        Created an attachment (id=27)
        Sample Test appliction

        Show
        dgothe added a comment - Created an attachment (id=27) Sample Test appliction
        Hide
        dgothe added a comment -

        Fix comitted to both trunk for jsf portlet 1.2 and jsf portlet 1.1 branch

        Show
        dgothe added a comment - Fix comitted to both trunk for jsf portlet 1.2 and jsf portlet 1.1 branch
        Hide
        dgothe added a comment -
            • Issue 34 has been marked as a duplicate of this issue. ***
        Show
        dgothe added a comment - Issue 34 has been marked as a duplicate of this issue. ***

          People

          • Assignee:
            jsfportletbridge-issues
            Reporter:
            dgothe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: