portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Finalizing Portal Navigation, [JIRA JS2-69]
Date Wed, 02 Mar 2005 09:59:42 GMT
Randy sorry for the late response but I've been too busy with the deployment
refactoring till now.

I think your plan looks good and I'm +1 in general.

For one usecase I don't yet see if/how your solution will handle it optimally
though.

My client has a setup which doesn't actually need real profiling.
There is only one content-type: html, one language/country: dutch, and there
are no different pages based on user/role/group: access is based only on
role and you either have it or you don't (no alternatives).

As far as I see, this setup doesn't really need a Site definition stored in
each user session: one instance for the whole portal would suffice.

The same applies to the menu requirements: there is only need for one set of
menu definitions shared by all users. Role restrictions should determine which
menu items are visible or not.

This usecase is very simple but nonetheless not uncommon for intranet business
application portals I think.
I can't think of a much lighter weight solution, and just for that reason only
it would already be good to have optimal and out-of-the-box support for.

Ate

watler@wispertel.net wrote:
> Team,
> 
> After devoting some time to this issue over the week I think I have come
> up with the heart of a proposal. I plan on commiting it to an official
> design document in all of its glory soon, but I would like some feedback
> first.
> 
> Here is the general scheme:
> 
> 1. An inital request comes in for a authenticated user immediately after
> login on some request url, (usually the portal root). Since this is the
> first request in a new session for the end user, the PageManager,
> Profiler, and new PortalNavigations component initializes a new context
> object that is attached to the session. This object will hold all cached
> profiled site information for the session to maximize reuse/scaling and
> hold sufficient state information about the user, pages, and active
> profiling rules to allow it to compute profiled site portal navigations
> dynamically later in the execution of the request pipeline.
> 
> 2. The "site" session context object is initialized/reset with only these
> elements when the ProfilerValve is invoked in the pipeline: the root
> folder, the current page, and a creation timestamp. All Folder, Page, and
> other document instances managed within the site session context object
> will be proxies that are arranged into a standard hirarchical site
> definition with the aid of the PageManager and Profiler. Unlike the
> current implementation, all elements managed by the site session context
> can be navigated to locate relative profiled site content, (i.e.
> getParent(), getSiblingFolders(), getFolders(), etc. will reflect the
> profiled site). These proxies will delegate all access and operations to
> the underlying objects managed by the PageManager, except those that
> maintain the proxy hierarchy. As mentioned, the initial site session
> context object will be sparsely populated. As the end user navigates
> through the portal and the Page Layout Templates are constructed, the site
> session context object will cache more of the profiled site definition by
> constructing the proxy hierarchy dynamically. The cached proxy hierarchy
> will be cleared when the session is destroyed or the PageManager cache is
> cleared due to a change in the physical PSML content.
> 
> 3. Basic utilities will be implemented by the site session context object
> that mimic the existing PageManager/Profiler features. These will
> minimally include: getPage(), getFolder(), getSiblingFolders(),
> getSiblingPages(), and getRootLinks(). The new getRootFolder(),
> getRootPages(), and getRootFolders() access will also implemented to
> facilitate ad-hoc access to the root of the profiled site.
> 
> 4. Document sets will be deprecated and replaced with named menu
> definitions that will appear in the folder.metadata files. In the broadest
> terms, these new folder based menu definitions will be a super set of the
> existing document set features. In addition to the ability to define and
> profile multiple menu definitions using alternate profiling rules and
> regular expression path sets, new capabilities based on explicit XML menu
> tags to define ragged nested menus inline will be implemented. Also,
> common menu design patterns/idioms can be easily specified using the
> declarative XML menu tags, (e.g. it would be trivial to define a simple
> XML definition to specify a menu tree composed of all root level folders
> and their pages). Individually named menu definitions will be inherited,
> (in a strictly non-aggregating style), down the profiled PSML hierarchy as
> one would expect so that they can be overriden in lower levels in the
> site. When accessed by the Page Layout Templates, the site session context
> object will construct and cache each named menu definition using another
> hierarchy of proxied Folder, Page and other document instances. This proxy
> hierarchy can be easily navigated by the Page Layout Templates to generate
> many simple or cascading Portal Navigation styles.
> 
> 5. The implementation of the functionality behind the site session context
> object and its proxy hierarchies will be encapsulated in a separate
> component I am referring to as the PortalNavigations component. I am also
> considering the implementation of another compatible component that simply
> returns underlying Folders, Pages, and other documents from the
> PageManager without employing the Profiler or Security; this would also
> eliminate the need for proxies and delegation. Given the flexibilty of the
> intended APIs outlined above, I am not sure there is a need to micro
> componentize the full function PortalNavigations functionality. By only
> computing exactly what a Page Layout Template requests and employing
> session based caching, it is not clear that any performance advantage
> would be realized by further decomposition. However, I am still
> considering the implementation of individual menu definition idioms as
> components.
> 
> 6. At the moment, I am assuming that different Page Layout Templates would
> be developed for the different HTML/javascript menu presentation styles.
> However, it would be relatively trivial thing to provide a menu
> presentation style attribute to the menu definition XML tags if we felt
> that having one template support multiple presentation styles was ideal.
> 
> 7. I am also initially requiring that default menu definitions would be
> placed in root folder.metadata files. This will allow them to be profiled,
> and thus overriden, as is done with all PSML content. However, it might be
> desirable to allow menu definitions to be specified in the
> PortalNavigations Spring configuration or by other valves in the request
> pipeline. I am not intending to support these or other alternatives in
> this implementation unless someone can come up with a compelling use case.
> 
> Whew! Ok gentlemen, pick up you stones and have at the straw man!
> 
> Randy
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message