[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59658 ] Scott T Weaver commented on JS2-69: -----------------------------------
Randy Walters reply (pulled from a direct reply email) I understand your aim here and am generally supportive of your ideas. An equally important requirement is to isolate the logic from the underlying PSML content implementation, (file system/XML, DB, CMS, etc.). Still, the biggest question remains: what is that set of minimal solutions we want to provide? We have three proposed or existing implementations so far: - XML based menu definitions, - regex path set menu definitions, and - the existing page relative navigation set. I am guessing that these could be broken into multiple components that share a common base implementation that facilitates interaction with the profiler and folder/document representations, (where security is implemented). I think the the primary reason to break these features into separate modules/components will be to avoid unnecessary/unused computed results. The only wrinkle here is that it might be interesting to use multiple components simultaneously. For example, top level navigations might use an XML menu definition and page relative sibling folders and pages could be used for deeper levels in the site beyond the top few folders. Another question is whether the various approaches can be unified under one API for use by the layout templates. I am still pondering this, but on the surface it seems that it might just add more confusion than it is worth. If the API becomes too generic, (like simply providing all profiled pages and folders in one big graph/hierarchy), all of the layout logic will simply end up moving into the templates... I do not think we want that, (or do we)? In the end, we might need to avoid doing ANY navigation computation in advance and defering it alltogether until the layout templates actually request a particular navigation elements set. I am not sure how that would be best implemented as individual components. Still thinking! Randy > 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]
