Re: Finalizing Portal Navigation, [JIRA JS2-69]
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 [EMAIL PROTECTED] 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 a
Re: Finalizing Portal Navigation, [JIRA JS2-69]
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 [EMAIL PROTECTED] 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 functionalit
Finalizing Portal Navigation, [JIRA JS2-69]
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 attri