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
