[Beehive Wiki] Update of "Design/PortletScoping" by RichFeit

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Beehive Wiki" for change notification.

The following page has been changed by RichFeit:
http://wiki.apache.org/beehive/Design/PortletScoping

The comment on the change is:
Some updates after discussion with Carlin.

------------------------------------------------------------------------------
  === Details ===
  All getting/setting of session-scoped attributes for page flow, page flow nesting stack, shared flow, and JSF backing bean instances uses {{{ScopedServletUtils.getScopedSessionAttrName()}}} to construct the actual session attribute name.  By default, this API returns the attribute name unmodified.  If either of the following two conditions are true, then the Scope ID is prefixed to the attribute name:
    * The current request is a {{{ScopedRequest}}}.  {{{ScopedRequest}}} is a wrapper over {{{HttpServletRequest}}} that we use when running inside a portal (more details below).
-   * A special request parameter ({{{ScopedServletUtils.SCOPE_ID_PARAM}}}) exists.  This is used to support multiple active page flows in the session, usually for multiple browser frames/windows.  It's important to note that the scoping mechanism is exactly the same as what it is for {{{ScopedRequest}}}/Portal, so a browser window using this mechanism could talk to the page flow from a ''portlet'' with the same Scope ID.
+   * A special request parameter ({{{ScopedServletUtils.SCOPE_ID_PARAM}}}) exists.  This is ''not inherently part of portal support.''  It is used to support multiple active page flows in the session, usually for multiple browser frames/windows.  It's important to note that the scoping mechanism is exactly the same as what it is for {{{ScopedRequest}}}/Portal, so a browser window using this mechanism could talk to the page flow from a ''portlet'' with the same Scope ID... but in the end it can be used on its own.  The {{{targetScope}}} attribute on NetUI tags like {{{<netui:anchor>}}} is a convenience for setting this parameter.
  
  === Issues and Future Directions ===
  If NetUI changes to use a NetUI-controlled ''context object'' for things like request/session access, then this context object can be smart about whether to create scoped attribute names.  It would eliminate the need for calling {{{ScopedServletUtils.getScopedSessionAttrName()}}} whenever setting a managed session attribute.
@@ -34, +34 @@

  === Issues and Future Directions ===
  A {{{URLRewriter}}} should be responsible for '''decoding''' scoped parameter names, in addition to its current responsibility for rewriting parameter names to be scoped.  Currently, our {{{ScopedRequest}}} (and the rest of the scoping package) assumes that scoping is done by prefixing the Scope ID to the name.  A portal URL rewriter currently has to know this implicitly.
  
- A portal framework is in charge of persisting scoped request attributes as necessary for use during "refresh" requests (requests that involve user interaction with a different portlet than the one being refreshed).  In the case where the NetUI framework knows an attribute ''should'' be persisted, it should use some API for marking a request attribute with a persist-hint, which the portal framework could use as it pleases.  Probably the best thing would be to have this information (which attributes have the persist-hint set) retrievable on {{{ScopedRequest}}}.
+ A {{{ScopedRequest}}} obtained through {{{ScopedServletUtils.getScopedRequest()}}} can be configured to "see" a request attribute on the outer request if it's not present in the scoped request.  NetUI may currently break when this is turned on (something to do with URL rewriters).  We should make sure to work in this situation.
+ 
+ A portal framework is in charge of persisting scoped request attributes as necessary for use during "refresh" requests (requests that involve user interaction with a different portlet than the one being refreshed).  In the case where the NetUI framework knows an attribute ''should'' be persisted, it should use some API for marking a request attribute as "persistable".  Something like {{{ScopedServletUtils.setPersistableAttribute()}}} and {{{ScopedServletUtils.markPersistableAttribute()}}} (the latter would be to mark an attribute that's already been set, like some of the ones set by Struts).
  
  Related to the above, there are some attributes that should be persisted, but which are large.  An example is a Struts {{{ModuleConfig}}}, which can be reconstructed based on the module path.  NetUI could offer a {{{ReconstructibleAttribute}}} abstract base class that {{{ScopedRequest}}} would be aware of:
- 
  {{{
      public abstract class ReconstructibleAttribute
      {
          private transient Object attribute;
-         private Object key;
+         private Object reconstructionKey;
+ 
+         public ReconstructibleAttribute(Object attribute, Object reconstructionKey) {
+             this.attribute = attribute;
+             this.reconstructionKey = reconstructionKey;
+         }
+ 
          public void dropAttribute() {
              attribute = null;
          }
+         
-         public abstract void reconstructAttribute(RequestContext context);
+         public abstract void reconstructAttribute(ServletRequest request, ServletContext servletContext);
      }
  }}}
  
- When persisting attributes, a portal framework could call {{{dropAttribute()}}} on anything that derives from {{{ReconstructibleAttribute}}}.  {{{ScopedRequest}}} could automatically call {{{reconstructAttribute()}}} as necessary when reading attributes.
+ Also, a {{{PeristableAttribute}}} for attributes that can be persisted as-is:
+ {{{
+     public class PersistableAttribute extends ReconstructibleAttribute
+     {
+         public PersistableAttribute(Object attribute) {
+             super(attribute, attribute);
+         }
+ 
+         public void reconstructAttribute(ServletRequest request, ServletContext servletContext) {
+             attrible = key;
+         }
+     }
+ }}}
+ 
+ Calling {{{ScopedServletUtils.setPersistableAttribute}}} would set a {{{ReconstructibleAttribute}}} in the {{{ScopedRequest}}}.  Calling {{{getAttribute()}}} on {{{ScopedRequest}}} would get the ''value'' of a {{{ReconstructibleAttribute}}} (reconstructing as necessary).  When persisting attributes, a portal framework could call {{{dropAttribute()}}} on anything that derives from {{{ReconstructibleAttribute}}} in the map returned by {{{ScopedRequest.getAttributeMap()}}}.
  
  == Response Scoping ==
  NetUI also includes a {{{ScopedResponse}}} wrapper that a portal framework would use to wrap the actual response.  The default implementation doesn't do much beyond keeping track of whether a redirect happened, and of errors/status-messages/cookies.