portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott T Weaver <scotts-jetspeed-l...@binary-designs.net>
Subject Re: [J2] Menu implementation
Date Sat, 19 Jun 2004 13:45:15 GMT
On Fri, 2004-06-18 at 17:57, Ate Douma wrote:
> David Sean Taylor wrote:
> 
> > 
> > On Jun 18, 2004, at 2:31 PM, Ate Douma wrote:
> > 
> >>>>
> >>>> 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.
> >>>>
> >>> If you look at the current PSML, ACLs are defined on the page and 
> >>> fragment level
> >>
> >> Yes. I know.
> >> But I still don't know where to specify an ACL on a subfolder, or in 
> >> which
> >> order I want my pages / subfolders be displayed in a menu (other than
> >> alphabetically).
> > 
> > 
> > A subfolder is just a page (PSML) right?
> Wow. I didn't get that one yet.
> I have the impression Scott wants to derive folders directly from
> filesystem folders.
Yes.  That is exactly what I had in mind.

> His comment on 6/16/2004:
>  >> Do I understand it now correctly that folders (for a file based Page Manager)
>  >> are simply derived from filesystem folders?
>  > That is how I see it.  Or possibly using a VFS file system.
> Furthermore, how would that psml look like? If a folder is a page, a folder
> contains pages, and pages are all defined in their own psml you need external
> references to define containment...
> 
> > So the ACL is on the page in its respective PSML file
> > 
> > For ordering, you need some metadata on the top level page
> > 
> >> And, menu rendering depth probably will be the same for all pages within
> >> a folder (and even pages within subfolders thereof).
> >> Seems kinda strange to have to define this on each and every page.
> > 
> > 
> > I think I misunderstand this. Wouldn't the menu for a page only have the 
> > menu-items from the immediate subpages (by default) below it?
> > The user could then add or remove(disable) as needed
> Normally not.
> Consider a menu of depth 2 (Scott's example).
> If I'm on a page from depth 1 and navigate to a page from depth2 wouldn't I want
> to see the exact same menu (only indicating a different selection).
> And if I navigate to a page from depth 3 I probably again want to see the same
> menu. The parent folder (depth 2) menu item should then be selected.
> A tree type menu (on the left) of unlimited depth starting from depth 3 would then
> indicate the current page selection.
> This is only one use case but a valid and a very common one I think.
Yes, Ate this is a perfect use case.  I would like to here others takes
on use cases also just so we don't miss something.

> 
> > 
> >> Menus based on folder navigation really are somewhat 'above' pages and 
> >> even
> >> folders.
> >> I don't want to update all of them just to increase/decrease the depth.
> >>
> > Im sorry but I don't understand what you are saying here
> If you take the example I gave above, the menu (depth) configuration really should
> be defined on the 'top' folder and be inherited/enforced below. If we need to define
> this on or through each and every page definition it becomes troublesome to update it.
> 
> > 
> >>>> 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.
> >>>>
> >>> Why not have menu metadata in the PSML?
> >>
> >> See above why that may not be so nice...
> >>
> > You lost me again. Do you mean immediately above?
> > The whole point of PSML is that has a model that can be customized.
> > When you customize, you manipulate PSML
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > 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