ICEfaces
  1. ICEfaces
  2. ICE-1393

Implement 'window' custom scope

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6DR#2
    • Fix Version/s: 2.0-Alpha2, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      all
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration

      Description


      ICEfaces extends the JSF Request scope into an Ajax environment via the interpretation that a "request" is defined as a full page refresh. In other words, interactions within a single window that do not cause a full page refresh reside within the same "request" scope, causing request-scope beans in ICEfaces to live longer than in standard web applications. This is useful as it allows request scope to distinguish between different windows and maintain the thread of a user's interactions with those windows, but it sacrifices the standard request scope (which is can useful for managing resources within a page).

      The ICEfaces request scope should be deprecated and a new explicit mechanism for "window flow" scope should be added. For instance, to instantiate com.mycompany.beans.WindowBean and name it myWindowBean:

      <managed-bean>
          <managed-bean-name>ScopeManager</managed-bean-name>
          <managed-bean-class>org.icefaces.application.ScopeManager</managed-bean-class>
          <managed-bean-scope>session</managed-bean-scope>
          <managed-property>
              <property-name>myWindowBean</property-name>
              <value>com.mycompany.beans.WindowBean</value>
          </managed-property>
      </managed-bean>

      This syntax, however, does not allow any interesting dependency injection or configuration of properties of beans in window flow scope. Instead, it may be preferable to define the desired beans in "none" scope (causing it to be instantiated only when it is referenced) and then register the names of those beans in a list on the ScopeManager.

      <managed-bean>
          <managed-bean-name>myWindowBean</managed-bean-name>
          <managed-bean-class> com.mycompany.beans.WindowBean </managed-bean-class>
          <managed-bean-scope>none</managed-bean-scope>
          <managed-property>
              <property-name>property1</property-name>
              <value>42</value>
          </managed-property>
      </managed-bean>

      <managed-bean>
          <managed-bean-name>ScopeManager</managed-bean-name>
          <managed-bean-class>org.icefaces.application.ScopeManager</managed-bean-class>
          <managed-bean-scope>session</managed-bean-scope>
          <managed-property>
              <property-name>WindowScopeBeans</property-name>
              <values>
                  <value>myWindowBean</value>
                  <value>myOtherWindowBean</value>
              </values>
          </managed-property>
      </managed-bean>

      It may also be necessary to implement a custom EL resolver to provide this capability.

      Oracle ADF Faces has a pageFlow scope which may have the desired properties:
      (however, beans in pageFlow scope are referred to in EL by the pageFlowScope prefix, which may not be desirable. In any case, it is possible we should adopt the "page flow" terminology)

      http://www.orablogs.com/jjacobi/archives/000481.html

      Spring Web Flow also has a number of good ideas in the same area:

      http://www.springframework.org/webflow

        Issue Links

          Activity

          Hide
          Ted Goddard added a comment -

          Is this a ThreadLocal for the scope itself? Would it be possible to just use the FacesContext in some way? If we can avoid our own ThreadLocal, we can avoid certain types of memory leaks.

          Show
          Ted Goddard added a comment - Is this a ThreadLocal for the scope itself? Would it be possible to just use the FacesContext in some way? If we can avoid our own ThreadLocal, we can avoid certain types of memory leaks.
          Hide
          Mircea Toma added a comment -

          Yes, the ThreadLocal holds the scope itself, although it would suffice to hold only the window ID string.

          We could put it in session or application map, but you know I'm not a fan of this approach. I actually tried this approach but the code started to become unwieldily when handling requests without window ID. When WindowScopeManager assigns a new ID WindowELResolver cannot lookup by ID the scope map because the ID is still internal to WindowScopeManager for the current thread. Only the next request would contain the window ID that can eventually be used by WindowELResolver to lookup the map.

          Also, by using the ThreadLocal lookups in session map, map of window scope maps, and request parameter map are avoided.

          Show
          Mircea Toma added a comment - Yes, the ThreadLocal holds the scope itself, although it would suffice to hold only the window ID string. We could put it in session or application map, but you know I'm not a fan of this approach. I actually tried this approach but the code started to become unwieldily when handling requests without window ID. When WindowScopeManager assigns a new ID WindowELResolver cannot lookup by ID the scope map because the ID is still internal to WindowScopeManager for the current thread. Only the next request would contain the window ID that can eventually be used by WindowELResolver to lookup the map. Also, by using the ThreadLocal lookups in session map, map of window scope maps, and request parameter map are avoided.
          Hide
          Ted Goddard added a comment -

          Window scope could be viewed as a sub-scope of session, also, it may be desirable for window-scoped values to be propagated for failover via session replication. Maybe just the windowID should be kept in the ThreadLocal?

          Show
          Ted Goddard added a comment - Window scope could be viewed as a sub-scope of session, also, it may be desirable for window-scoped values to be propagated for failover via session replication. Maybe just the windowID should be kept in the ThreadLocal?
          Hide
          Ted Goddard added a comment -

          Checked in the following change temporarily since a different value for window.ice.window was causing a failed full-page refresh in compat/component-showcase. (The script node is a direct child of the <body>.) We should look at alternative methods for passing parameters to the bridge. A cookie will likely not be suitable in this case since this bridge parameter is window-specific (cookies were proposed as a parameter passing mechanism for other bridge configuration).

          public void encodeBegin(FacesContext context) throws IOException {
          ResponseWriter writer = context.getResponseWriter();
          writer.startElement("script", this);
          + writer.writeAttribute("id", "ice-window-init", null);
          writer.writeAttribute("type", "text/javascript", null);
          writer.writeText("window.ice.window = " + id + ";", null);
          writer.endElement("script");

          Show
          Ted Goddard added a comment - Checked in the following change temporarily since a different value for window.ice.window was causing a failed full-page refresh in compat/component-showcase. (The script node is a direct child of the <body>.) We should look at alternative methods for passing parameters to the bridge. A cookie will likely not be suitable in this case since this bridge parameter is window-specific (cookies were proposed as a parameter passing mechanism for other bridge configuration). public void encodeBegin(FacesContext context) throws IOException { ResponseWriter writer = context.getResponseWriter(); writer.startElement("script", this); + writer.writeAttribute("id", "ice-window-init", null); writer.writeAttribute("type", "text/javascript", null); writer.writeText("window.ice.window = " + id + ";", null); writer.endElement("script");
          Hide
          Mircea Toma added a comment -

          Store window IDs into the the threa local instead of the window scope ap to avoid memory leaks.

          Show
          Mircea Toma added a comment - Store window IDs into the the threa local instead of the window scope ap to avoid memory leaks.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: