Finalizing Portal Navigation, [JIRA JS2-69]

[wa...@wispertel.net]

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

Re: Finalizing Portal Navigation, [JIRA JS2-69]

[Randy Watler <wa...@wispertel.net>]

Ate,

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 
somehow.

Randy

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

Re: Finalizing Portal Navigation, [JIRA JS2-69]

[Ate Douma <at...@douma.nu>]

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