[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59483 ] Randy Watler commented on JS2-69: ---------------------------------
After reviewing Ate's proposal and comments from 7/3/2004, (http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=15857), and factoring in recent discussions on the topic, it seems that there is the beginning of a consensus around providing a profiled view of folders and pages from the root to a specified depth. This top level "site map" could be used to drive global portal navigations that supplement or replace the existing page relative navigation elements. Generally, the goal is to provide some basic information "out of the box", (i.e. w/o the need for document sets or other configuration information), to support typical navigations for small to medium sized portals. Support for profiling is a must, so simply returning a reference to the underlying physical view of the portal content is not acceptable. However, a hierarchical object representation of the "site map" that contains profiled folders and documents is probably required to allow nested menu representations including javascript dhtml pulldown renderings to be constructed easily. The desired "depth" of the root level "site map" would probably need to be somewhat variable to support ragged pulldown menu trees. Consequently, it seems that some form of a menu definition will be required, minimally some kind of path set specification like: "{/*,/*/,/deep0/*,/deep1/*,/deeper/*/}". Of course, a simple default like "{/*,/*/*}" would due in many cases. If paths are too limiting, a full XML menu definition might be required... but there have been other votes against such a thing. This "site map" would probably be specified globally, or possibly at the individual folder level. If folder level specification is required, it should support some form of inheritance so that navigations specified in the root or parent folders would serve as the default folder menu definition. Given that the profiler would be used to generate this "site map", it does not seem that any capability to specify multiple menu definitions per user, group, role, mediatype, etc. would be needed or desirable. Instead, the contents of a single "site map" would be determined by profiler folder aggregation and security filtering. If folder level specification is implemented, the specific folder and menu definition could also be selected by the profiler as a by product of selecting the portal page to be displayed. Caching of these portal "site maps" can be significantly easier than reusing the existing navigational elements generated today. In fact, if folder level specification is not supported and a single global menu definition is allowed, the resulting "site map" can be generated once and cached per session. This advantage should be carefully considered when making the decision to support folder level specification. > Finallizing Portal Navigation using the Profiler > ------------------------------------------------ > > Key: JS2-69 > URL: http://issues.apache.org/jira/browse/JS2-69 > Project: Jetspeed 2 > Type: New Feature > Components: Profiling/Portal Navigation > Versions: 2.0-dev/cvs, 2.0-a1 > Reporter: Scott T Weaver > Assignee: Randy Watler > Priority: Critical > > We still haven't settled on how we are going to generate navigations in J2. > I have some modifications to the Profiler and to the theme logic which may > give us some direction. I am bringing this up as I have been privellage to > quite a few vendor portal demos lately allowing me to see both the good and > the bad of multiple implementations. > - I would say we replace the getDesktop() with getFolders(). There is really > no need for a "root" item or Folder per se since we will be leaving this job > to the current set of profilling rules that have been assigned to the > Profiler. > - Folders will contain any number of pages and/or folders. > - Folder items would be ordered the following way: first by assigned index > then by alphabetical order. > - Remove defaultPage logic from Folder, the focused Folder item would be set > in this fashion: set the focus to the last selected child in that Folder then > by Folder Item ordering algothrim defined above. > - It should be the Profiler's responsibility to preserve a user's active item > on a per Folder basis. > - A Folder would still posses the defaultTheme capabillity but with the added > abillity to enforce the defaultTheme on its childern and its childrens' > children by overriding the theme settings for those items with its own. > - Rendering the contents of the Profiler.getFolders() would be left entirely > up to the theme (currently called the layout decorator). Example: a theme > could render the first 2 levels as tabs and the rest as a hierarchical menu > to the left of the layout area. > - DO NOT introduce the idea of controls and controllers. It has been stated > before that these easily confuse people and I agree 100%. We need to keep > things simple. > I think the first profiling/navgation implementation would be assigning n > number of roles to a top-level folder. Then allow the Profiler to aggregate > what Folders a user has access to by comparing the roles that user is > assigned to the ones required the Folders required roles (ACL?) I think this > approach is already somewhat in place but it just needs some final > implementation details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
