On Jun 18, 2004, at 1:35 PM, Ate Douma wrote:
Scott, thanks for the answers. I still do have a few questions though...This seems to limit a user to only one home page or would it be more like in j2
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.
/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 haveI apologize for being unclear on this. Renderers would not be defined
> 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?
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
If you look at the current PSML, ACLs are defined on the page and fragment levelA 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.
Why not have menu metadata in the PSML?
Im still thinking we need some kind of meta information in the PSML regarding the menuOrdering 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'm not sure what you agreed to: not needing .menu, or losing ACL inheritance?I think I do like this proposal so far. I can even see we might not needAgreed. -1 on menus.
.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?
Concerning folder ACL, see my question above?
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 [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
