Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of richfeit@gmail.com designates
 64.233.162.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding;
        b=GhGIvJvaDhzlfRn6Lbt5K9ZyepZ6HfQHEJa0WomfOOqlzP+Jbp6kUo/PTZMZPgtZ7zTg3F4vtvZGqPm6jsDsfxR2/rW29+QOGoPMqibO7zFHwUBnLqzBGdUDqVVGD9oTqMiSl39wkO+ztLlq8qia9ONS8DtHnUCwhBydSiiZJN4=
Message-ID: <43209239.3030502@gmail.com>
Date: Thu, 08 Sep 2005 13:34:17 -0600
From: Rich Feit <richfeit@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@beehive.apache.org
Subject: [post-1.0] request attribute issues for NetUI under portals
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

While we're waiting for the last few issues to wind up for 1.0, I wanted
to throw out there a question/issue I have about supporting NetUI
first-class under portals (something I'm sure we'll be discussing as we
get into post-1.0 planning).  NetUI currently has the underpinnings of
Portal support (in the form of ScopedRequest), but there isn't a bridge
to make it work in a JSR168 Portlet environment.  This is a specific
issue that I think we'll end up facing.

** Background **
Portal environments that use NetUI/Page Flow will have the option of
temporarily storing request attributes in the session, so that on a
portal refresh request (one where the interaction is with another
portlet), the attributes aren't lost on the page that's currently being
displayed.  Using this system, though, it's possible to allow large
request-scoped attributes into the session, which is unacceptable.

** Proposed Solution **
- By default, calling request.setAttribute() sets an attribute that
*will not* get persisted.

- When any code in the NetUI framework sets a request attribute that
should be persisted, it goes through a special API.

- When any code in the NetUI framework sets a request attribute that
should not be persisted, but which can be reconstructed automatically
based on some basic information (e.g, a ModuleConfig object that can be
reconstructed from the String module path), it goes through an API that
accepts an interface (~ReconstructibleAttribute).  An implementor of
this interface can reconstruct the object, given current request context.

Thoughts on this?  It's a good puzzle to keep your mind occupied as we
ship... :)

Rich