portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] Menu implementation
Date Fri, 18 Jun 2004 21:09:06 GMT

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

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

> 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


Mime
View raw message