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 21:31:35 GMT


David Sean Taylor wrote:

> 
> On Jun 18, 2004, at 1:35 PM, Ate Douma wrote:
> 
>> Scott, thanks for the answers. I still do have a few questions though...
>> See below.
>>
>> Scott T Weaver wrote:
>>
>>> 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.
>>
>>
> This seems to limit a user to only one home page or would it be more 
> like in j2
> 
> /home/scott/default
> 
>> I'd like the idea but would want it optional, maybe even per 
>> user/group/role.
>>
> Why not have any arbitrary number of roots?
> This allows someone to layout their site however they choose
> I like the concept of /home, which is the equivalent of /users in J1
> /group and /role roots could also be useful if you wanted a place to 
> naturally secure pages by group or role like in J1
> But we should not limit it to only 3 roots as in J1
> 
> 
>>>> > 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.
> 
> 
> So is a renderer any different from a page layout? or decorator?
> In this proposed model, Im having trouble understanding how we are 
> making the concept of menus easier to understand
> A user just wants a menu and I find the renderer terminology to be 
> overloaded and complicated for portal design at this level
> 
> Can I step back and ask: What functionality does a menu provide?
> 
> For me menus provide navigation links and require:
> 
> 1. menus need to allow me to navigate to any page in the portal using a 
> normalized URI model
> 2. menus should not appear if you do not have access to them (secured)
> 3. menus should allow me to navigate outside the portal, and secure 
> (possibly thru SSO) access to that page
>     (it could be argued that a portlet could provide the same, but in my 
> experience in this area, I find this more of a navigational link)
> 4. menus should allow me to display a single portlet in a given 
> mode/state (i.e. maximized/normal) from the current page, or another page
> 
> Say we have a page called
>  From my home page, I would like to have a menu with four simple options
> 
> 1. My Stuff
> 2. The HR App
> 3. Marketing Docs
> 4. Maximized View of Calendar Application
> 
> #1 = a page found under my home: /home/david/mystuff
> #2  = an external link outside the portal: http://hr.mycompany.com/
> #3 = a link to the /marketing/documents/2004/ page
> #4 = a portlet on this page (or another page) maximized
> 
> 
>>> 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.
>>
> 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).
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.
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.

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

> 
>> 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?
>>
> Im still thinking we need some kind of meta information in the PSML 
> regarding the menu
> Im also not sure about making subfolders and menu-options on a 1:1 basis
> There may be subfolders which I do not want to display or hide for a 
> period of time
> 
> Don't get me wrong, unlike J1, Im beginning to agree to the idea of 
> menus defined at the page level ONLY
> and doing away with complex menus inside fragments inside fragments on end
> At least it seems much easier for the end user to grok
> 
> -- 
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> [office]   +01 707 773-4646
> [mobile] +01 707 529 9194
> 
> 
> 
> ---------------------------------------------------------------------
> 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