David Sean Taylor wrote:
Randy Watler (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59483 ]First let me say that the profiled navigation is very powerful and very useful for me. I have several sites running using role-based aggregation of navigations, and it works great. On the negative side, it wasn't easy to configure. What we need is something very intuitive that can be tooled into a UI so that site maps can be created easily. I agree with Randy: we need a better abstraction. Perhaps the site map abstraction is right.
Randy Watler commented on JS2-69:
---------------------------------
From my experience and user requirements, I had trouble getting menus to match the folder/page tree. I spent hours trying to get the algorithms to produce something that I could much more easily and more and intuitively generate with a declarative XML menu data structure. (yes im bringing this up again.)
> 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.
One use case that keeps popping up is a rootless tree.
I find myself working around the root. If I have a need for for top menus as folders, and then submenus as psml, i have to move one arbitrary folder down into the root.
> "{/*,/*/,/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.
not my vote
> Given that the profiler would be used to generate this "site map", it > does not seem that any capability to specify multiple menu definitions
Ive already written several applications using the profile per user approach along with navigations. I would suggest that dealing with backward compatibility is important
My opinion is that trying to build the menu on the fly off of the physical layer may not be the best approach. A better abstraction could leverage all the work Randy put into profiled-pages and navs. Perhaps this abstraction is a site map or a declarative xml menu in the folder metadata.
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
