On Fri, 2004-06-18 at 17:31, Ate Douma wrote:
> 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.
+1 to the thinking that pages are above navigation. That is why I want
to render the navigation at the decorator level.
I think we need to agree that the page itself has nothing to do with
navigation from the standpoint of rendering the navigation hierarchy.
>
> >
> >> 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
> > [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]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
