ICEfaces-EE
  1. ICEfaces-EE
  2. IPCK-340

Extended Request Scope for JSF 2.0

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: EE-2.0.0
    • Fix Version/s: EE-4.1.0.GA
    • Component/s: Core Extensions
    • Labels:
      None
    • Environment:
      ICEfaces 3

      Description

      Extended Request Scope is widely used by ICEfaces 1.x users and does not have a direct replacement in JSF 2.0 (window scope and view scope are similar, but may require code or behavioural adaptations). It is therefore desirable to have a mode for ICEfaces 3.0 that modifies RequestScope behaviour to match that of ICEfaces 1.x.

        Activity

        Hide
        Ted Goddard added a comment -

        Defining a new scope via the JSF 2.0 extension mechanism typically requires a number of changes to the application, so a different approach will be necessary.

        The initial behaviour of Request scope is as desired: when a new window is created, any referenced beans in this scope will be instantiated and stored in the RequestMap. The missing aspect is the "Extended" nature that propagates bean values across multiple Request scopes for the same window.

        It is important that this be implemented in a self-contained way that does not make use of JSF extension points with other side-effects.

        A combination of PhaseListener and NavigationHandler could be use to intercept the expiry of the RequestScope and copy the values into the session where they could be restored on the next request at the start of the JSF lifecycle.

        Differences from ViewScoped: values would not be serialized with the ViewRoot, and values would (optionally for the entire scope) always propagate across navigation.

        Differences from WindowScoped: values would be declared using the standard JSF Request scope, storage makes use of the RequestMap rather than an additional map.

        One complexity is the clearing of the scope when the window is closed. If this feature is not required, this complexity can be avoided.

        Show
        Ted Goddard added a comment - Defining a new scope via the JSF 2.0 extension mechanism typically requires a number of changes to the application, so a different approach will be necessary. The initial behaviour of Request scope is as desired: when a new window is created, any referenced beans in this scope will be instantiated and stored in the RequestMap. The missing aspect is the "Extended" nature that propagates bean values across multiple Request scopes for the same window. It is important that this be implemented in a self-contained way that does not make use of JSF extension points with other side-effects. A combination of PhaseListener and NavigationHandler could be use to intercept the expiry of the RequestScope and copy the values into the session where they could be restored on the next request at the start of the JSF lifecycle. Differences from ViewScoped: values would not be serialized with the ViewRoot, and values would (optionally for the entire scope) always propagate across navigation. Differences from WindowScoped: values would be declared using the standard JSF Request scope, storage makes use of the RequestMap rather than an additional map. One complexity is the clearing of the scope when the window is closed. If this feature is not required, this complexity can be avoided.
        Hide
        Ken Fyten added a comment -

        Closing as Won't Fix.

        Show
        Ken Fyten added a comment - Closing as Won't Fix.

          People

          • Assignee:
            Ted Goddard
            Reporter:
            Ted Goddard
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: