On Fri, 2004-06-18 at 11:50, Ate Douma wrote:
> As I'm the one who started this thread I will try to summerize the
> different positions and proposals I can digest myself from it.
> Before I do that though, if possible I would like a few more things
> cleared up.
>
> First of all, one (or more) response from Scott was never received on
> the list (see my previous comment on this thread).
> And, I asked a few questions which I didn't receive an answer to yet.
> I will repeat them again below and hopefully Scott (or someone else)
> can try to answer them.
> I will then try to write a summary this weekend.
>
> Scott T Weaver wrote:
> > This was exactly my reasoning for using menu/folder concept. I think a
> > good compromise would be this: standard navigation would be built using
> > the folder concept. However, we can introduce an optional "menu"
> > fragment that would be sourced from a .menu file that contained a
> > standardized xml format (like format proposed above).
> >
> > Next we introduce the idea of a navigation renderer that would consume
> > and render either .menu files OR folder/page structures.
>
> Per site or per root folder?
I am not sure what you mean about site? 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.
>
> > 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.
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.
>
> 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.
>
>
> Serge Huber wrote:
>
> >
> > I think it might also be a good idea if someone could summarize once
> > some kind of consensus is reached, or maybe update the existing spec,
> > because I must say this thread has not been very easy to follow,
> > especially for newcomers such as me :)
> >
> > Regards,
> > Serge Huber.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
