Portlet Scoping

Introduction

As underlying support for running NetUI applications within portlets (originally within BEA's proprietary Portal), the idea of scoping is present throughout the NetUI framework. There are two kinds of scoping:

Session Scoping

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:

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.

Request Scoping

URL Rewriting

A portal framework can register a URL rewriter that will prefix request parameters with the current Scope ID in any page rendered using NetUI tags. This makes the names unique, and targeted to a particular portlet. Some examples (assuming a portlet ID of "portletA":

The URL rewriter may rewrite the URL in other ways, but this is its main function as it relates to scoping.

ScopedRequest

A portal framework can create a ScopedRequest wrapper around a basic HttpServletRequest in order to decode scoped requests (normally requests that come from a page rewritten with a URL rewriter, above). The ScopedRequest does two main things:

In general, a ScopedRequest would be created/initialized by a portal framework in framework code (or even in a Servlet Filter) before NetUI ever sees the request.

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 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 reconstructionKey;

        public ReconstructibleAttribute(Object attribute, Object reconstructionKey) {
            this.attribute = attribute;
            this.reconstructionKey = reconstructionKey;
        }

        public void dropAttribute() {
            attribute = null;
        }
        
        public abstract void reconstructAttribute(ServletRequest request, ServletContext servletContext);
    }

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.

The most commonly-used APIs are in ScopedServletUtils:

Additionally, a portal framework will want to use the URLRewriterService API:

Design/PortletScoping (last edited 2009-09-20 23:24:20 by localhost)