portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Re: Finalizing Portal Navigation, [JIRA JS2-69]
Date Wed, 02 Mar 2005 10:44:50 GMT

If I am understanding your usecase correctly, you do not need profiling 
but you are depending on security constraints to modify the site/menu 
definitions per user. The site session context object is meant to be 
accessed directly by the layout templates, so I had intended to apply 
the security constraints while the site and menu definitions are being 
constructed out of the Folder/Page/Document proxies. I believe that in 
your usecase the caching would be optimally done per group/role instead 
of per session. However, if any security constraint specified in the 
PSML references a user, (even "guest"), the group/role optimization 
potentially breaks down and degenerates into the session context case.

At the moment, I do not think it would be worth scanning the PSML 
security constraints in an attempt to determine the appropriate/safe 
caching level for all site/menu definitions. Perhaps an advanced 
performance tuning flag might be appropriate in the Spring configuration 
for the PortalNavigations component. In the end, caching by group/role 
might not be significantly different from the session context caching... 
we'll have to see.

Thanks for the feedback! I will think about this usecase more... let me 
know if this response makes sense or if I managed to confuse the usecase 


Ate Douma wrote:

> 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

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

View raw message