portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [J2] Menu implementation
Date Fri, 18 Jun 2004 20:35:27 GMT
Scott, thanks for the answers. I still do have a few questions though...
See below.

Scott T Weaver wrote:

> On Fri, 2004-06-18 at 11:50, Ate Douma wrote:
> 
>>As I'm the one who started this thread I will try to summerize the
>>different positions and proposals I can digest myself from it.
>>Before I do that though, if possible I would like a few more things
>>cleared up.
>>
>>First of all, one (or more) response from Scott was never received on
>>the list (see my previous comment on this thread).
>>And, I asked a few questions which I didn't receive an answer to yet.
>>I will repeat them again below and hopefully Scott (or someone else)
>>can try to answer them.
>>I will then try to write a summary this weekend.
>>
>>Scott T Weaver wrote:
>> > This was exactly my reasoning for using menu/folder concept.  I think a
>> > good compromise would be this: standard navigation would be built using
>> > the folder concept.  However, we can introduce an optional "menu"
>> > fragment that would be sourced from a .menu file that contained a
>> > standardized xml format (like format proposed above).
>> >
>> > Next we introduce the idea of a navigation renderer that would consume
>> > and render either .menu files OR folder/page structures.
>>
>>Per site or per root folder?
> 
> 
> I am not sure what you mean about site?  
What I meant was if .menu or folder navigation would be configurable per root
folder OR only globally for Jetspeed as a whole (site).

> As for .menu, I am now feeling
> we should scrap that idea and just support additional content in folders
> such as .link files that point to other sites, etc.  Stick with folders
> as the only source for building navigation.
> 
> I would as like to introduce the idea of per user home folders:
> 
> home/ate
> home/scott
> ...
> 
> When aggregating folders, we would look at the current user, locate
> home/${current_user} display it as top level folder simply named
> "/home".  The user would be allowed to create any content he/she likes
> under this structure.  However, all other folder structures not under
> the user's home would be subject to the ACL assigned to it.
I'd like the idea but would want it optional, maybe even per user/group/role.

> 
> 
> 
> 
>> > You could have
>> > multiple navigation renders on a final portal page.  Renders could also
>> > be limited on the number of levels they should render.  For example, you
>> > could have tabbed renderer at the top of a page, and tell it to only
>> > render the first 2 nested levels of folders.  Then on the left hand side
>> > of the page, we have tree-like menu render that renders from level 3 on
>> > down.
>>
>>What I don't see how and where these folder navigation renderers are to be
>>defined. We need some kind of configuration for them...
>>Would you suggest special psml type definitions or something different?
>>If I interpreted this correctly I guess this can only be defined in/on the
>>root folder as all folders and pages below it will have to conform to the
>>same definition otherwise navigating within could lead to strange effects.
>>And possibly one standard site definition which could be overridden per
>>root folder?
> 
> 
> I apologize for being unclear on this.  Renderers would not be defined
> anywhere in the folder/page structure they are a view concern not a
> model concern.  
> Each layout decoration (theme?) would incorporate
> renders within their template.  I feel this makes the most sense in that
> a layout decoration would know best how to display navigation.  Heck,
> you could even package a layout decoration with it's own set of custom
> renderer templates.
> 
> A renderer would most likely be a snippet of Velocity which would be
> given a Folder objct from which it could render the folder and all of
> its children in a specific way.  I really see no need to complicate
> things by adding a FolderRenderer class/interface hierarchy.
> 
> Or we could just add a renderFolder(Folder, String) method to
> JetpseedPowerTool.
> 
> (in you layout template)
> $jetspeed.renderFolder(myFolder, "tabbed_folders.vm") 
> 
> and just let the template do the rendering.
What I'm still missing is where folder/menu specific configuration is
defined. Things like ordering (I've read JS2-69, but that doesn't tell
me more), ACL, menu rendering depth.

Menu rendering depth could be hard coded and/or configured within the layout
decoration but that would make it hard to modify through an Customizer.

Ordering and ACL really need some kind of model.

Are we going to need a .folder or folder psml after all?

If not, it doesn't feel 'right' to have to define a decoration (theme) on
each page which (partly) applies to its container, the folder.

> 
> 
>>I think I do like this proposal so far. I can even see we might not need
>>.menu file or embedded menu definitions after all.
>>Only having to define all these extra Pages (in contrast to the J1
>>implementation) which all reference the same decorators seems not so nice.
>>Furthermore, we would lose the ability to define acl inheritance etc. Or
>>should we also be able to define these on each folder? A folder really
>>is going to be much more than just a file system structure then...
>>And, these menus somehow are to be embedded into a rendered page.
>>Where are we to define these. In the page decorator?
> 
> 
> Agreed.  -1 on menus.
I'm not sure what you agreed to: not needing .menu, or losing ACL inheritance?
Concerning folder ACL, see my question above?

> 
>>
>>Serge Huber wrote:
>>
>>
>>>I think it might also be a good idea if someone could summarize once 
>>>some kind of consensus is reached, or maybe update the existing spec, 
>>>because I must say this thread has not been very easy to follow, 
>>>especially for newcomers such as me :)
>>>
>>>Regards,
>>>  Serge Huber.
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>.
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 
> 
> 
> 


---------------------------------------------------------------------
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