portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Date Wed, 23 Feb 2005 00:48:58 GMT


David Sean Taylor wrote:
> Randy Watler (JIRA) wrote:
> 
>>      [ 
>> http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59483 ]
>>      Randy Watler commented on JS2-69:
>> ---------------------------------
>>
> 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.
> 
>  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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message