portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wat...@wispertel.net
Subject Finalizing Portal Navigation, [JIRA JS2-69]
Date Mon, 28 Feb 2005 05:07:17 GMT

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

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

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!


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

View raw message