[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59657 ] Scott T Weaver commented on JS2-69: -----------------------------------
Ate Douma's comments (pulled from a direct response email) I'd like to propose we try to tackle this beast by using more divide and conquer. In my honest opinion, the current page context aggregation is very powerful, but also quite difficult to use. In a lot of situations, its full power isn't needed and can get more in the way than helping out... I'm currently refactoring the whole deployment functionality and the thing that is taking the most of my time is the complexity of the current implementation. The solution I'm following right now is stripping the whole thing to its bare bones and refactor whats left. J2 its most prominent architectural aspect is that it is component based down to the core. Although I've stripped a lot of deployment functionality, I found out that most of it isn't used (not by J2 itself at least, maybe others have already build upon some features we don't use yet). After I have finished the deployment refactoring, I'm willing to build then considered *lost* functionality back *on top* of the bare bones default deployment components, but only as optional, configurable enhanced components. Not back into the default/base/core components. Those I think we should always try to keep simple, slim and bare to the bones. For the Portal Navigation solution(s), I very much would like to see a similar strategy be used. Determine a few (at the most) very simple Navigation styles and build that as small, light and fast components. Once that would be in place, more powerful enhanced components can be created for handling the more complex solutions like the ones we have right now... I'm not actually working on this issue and don't have enough time available yet to get more involved so don't take my opinion as more than that. I know its way easier to write about it than doing it ;-) But, with my current experiences with the deployment refactoring I do think it might actually speed things up a lot... Ate > 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]
