You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2004/06/15 17:53:22 UTC
[J2] Menu implementation
I've been trying to get a clear picture of what the options and positions are about menu creation for J2.
I'm quite lost after reviewing several sources:
- 1) current J1 impl
- 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
- 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
([J2} Proposal for Layout, pages & Decorator handling in J2)
- 4) http://nagoya.apache.org/jira/browse/JS2-69
(Finalizing Portal Navigation using the Profiler)
A few design issues needs to be addressed I think to be able to decide on the impl. of menus.
- Nested pages
Should these be allowed?
Part of that question is what a Page is.
The pdf (see 2) says its to be considered a Fragment.
If this is meant as a "fragment" which can be included, alright. But, I don't see how it also can
be a "Fragment" (note the case) or why it should be made one.
Fragments already can contain other Fragments though. This is more or less in analogy to nested
portlets in J1 I belief.
Maybe one reason why one would want to nest pages is to be able to define different decoration on a nested page.
It has been suggested by Scott (see 4) to allow for the most flexible way possible this should be possible
(even up/down overrides if needed).
To me, this seems to lead to very complex psml though. I would certainly like to see a more
simple model implemented first before going that road.
Probably the same result could be created without page nesting using fragment references. These could
reference other pages (pulling in their decorator definitions with them) or fragments within other pages.
As far as I can tell, then there would be no need to define pages within pages.
- Folder or menu elements
The Folder concept containing other folders and/or pages could be used to generate menus as proposed by Scott (see 4).
Something I'm missing right now is a clear understanding how/where folders are defined. I found the om impl but no usage
yet so its something I can't relate to enough yet to really decide if I'm going to like it or not.
One important issue I would have with it though is that it wouldn't allow me to render page fragments/portlets in a
menu, not external links.
Likewise, I don't see how a TabbedPane could be rendered for the current page using the folder
concept.
The other proposal from David Taylor was defining new psml menu and menu-item elements which could reference pages,
(external) fragments and external links (see 3).
I understand Scott didn't like adding additional data structures into the mix (see 4), but I for one would prefer this
above the folder/page -> menu concept. AFAIK its way more flexible and probably much easier to understand for a user.
And, it isn't that different from the J1 implementation. Recreating the current J1 features for J2 will be relatively
easier to do I think.
Note: I know the folder concept is not *just* about menus. I'm not opposed to folders in anyway. I just think its
to restricted for menu rendering.
I'd like some comments and if already possible a vote which way we should go about menu rendering.
I know I'll something soon ;-)
Regards,
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
On Wed, 2004-06-23 at 10:02, Ate Douma wrote:
> Scott T Weaver wrote:
>
> >>*Menu Decorator*
> >>A Menu Decorator is used by a Page Decorator to do the actual rendering of a menu. Depending on the Page Decorator
> >>capabilities, zero, one or more menus may be rendered on a Page. A Page Decorator could support a top tab menu and
> >>a left tree menu for instance.
> >
> > I just want to make a point that this should not be a java class but a
> > simple template fragment.
> +1
>
> >>Additionally, a Folder can be configured to be skipped for current level determination. Those Folders are traversed for
> >>menu rendering but not included by it (nor its non-Folder elements). For instance the Folders used by the
> >>Profiler to find a matching Page (e.g. client capability Folders as wml or html, language Folders as en, fr, nl) could
> >>be skipped.
> >
> > I think there should be support automatically skipped folders like those
> > associated with l10n and content type.
> +1. It would lead to tight coupling with the Profiler though I guess...
>
> >
> >>*Page Decoration* (or skin)
> >>A Page Decoration supplies a css style and optionally image references to be used by a Page Decorator.
> >>Furthermore, a Page Decoration can supply default css styles and optionally image references to be used by Menu
> >>Decorators and Portlet Decorators.
> >>
> >>*Menu Decoration* (or skin)
> >>A Menu Decoration supplies a css style and optionally image references to be used by a Menu Decorator.
> >
> > I think we should just stick with the page decoration controlling this.
> It's already optional :-)
> I described for the Page Decoration that it can contain defaults for both the Menu and Portlet decorators (see above).
> Its not uncommon that menus look quite differently from the rest of a page. Being able to change only the Menu styles
> would be a nice feature (especially for end users) I think.
> But, its not a requirement on my side. If we don't like it: drop it.
>
> >
> >
> >>*Portlet Decoration* (or skin)
> >>A Portlet Decoration supplies a css style and optionally image references to be used by a Portlet Decorator.
> >
> > This already taken care of by the portlet decorator. Are we going to
> > separate the 2 now? I think I like that idea as it makes development of
> > decorators/decorations that much more complicated
> Scott, I'm not sure I get what you are saying.
>
> Could you please choose only ;-) one below:
> a) you like the separation because it will make development more complicated
> b) you like the separation because otherwise the development will be more complicated
> c) you don't like the separation because it will make development more complicated
> d) you don't like the separation because otherwise the development will be more complicated
>
Survey says: c ;)
>
> > I am very against extensive meta-data for folders. Plus, there should
> > be no "id" required for a folder as it is already uniquely identified by
> > its root-relative path.
> +1.
>
> I'm against extensive meta-data too. This is just a first shot of an example in which I wanted to show all
> the options. I should have know this would send the wrong message without explaining it as such.
> Also, this proposal is meant as food for discussion.
> I'm not stuck to this design, I just happen to like it.
> Meta-data configuration is mostly implementation level too me. We should be able to come to an
> agreement on that afterwards. The main design concepts should first be agreed upon.
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
Overall, this proposal is looking great! I think we are at stage were
we can start developing a model from a code point of view.
Let's make sure we make heavy use of the wiki since I can already tell
this isn't going to a be a one man effort ;)
On Wed, 2004-06-23 at 10:02, Ate Douma wrote:
> Scott T Weaver wrote:
>
> >>*Menu Decorator*
> >>A Menu Decorator is used by a Page Decorator to do the actual rendering of a menu. Depending on the Page Decorator
> >>capabilities, zero, one or more menus may be rendered on a Page. A Page Decorator could support a top tab menu and
> >>a left tree menu for instance.
> >
> > I just want to make a point that this should not be a java class but a
> > simple template fragment.
> +1
>
> >>Additionally, a Folder can be configured to be skipped for current level determination. Those Folders are traversed for
> >>menu rendering but not included by it (nor its non-Folder elements). For instance the Folders used by the
> >>Profiler to find a matching Page (e.g. client capability Folders as wml or html, language Folders as en, fr, nl) could
> >>be skipped.
> >
> > I think there should be support automatically skipped folders like those
> > associated with l10n and content type.
> +1. It would lead to tight coupling with the Profiler though I guess...
>
> >
> >>*Page Decoration* (or skin)
> >>A Page Decoration supplies a css style and optionally image references to be used by a Page Decorator.
> >>Furthermore, a Page Decoration can supply default css styles and optionally image references to be used by Menu
> >>Decorators and Portlet Decorators.
> >>
> >>*Menu Decoration* (or skin)
> >>A Menu Decoration supplies a css style and optionally image references to be used by a Menu Decorator.
> >
> > I think we should just stick with the page decoration controlling this.
> It's already optional :-)
> I described for the Page Decoration that it can contain defaults for both the Menu and Portlet decorators (see above).
> Its not uncommon that menus look quite differently from the rest of a page. Being able to change only the Menu styles
> would be a nice feature (especially for end users) I think.
> But, its not a requirement on my side. If we don't like it: drop it.
>
> >
> >
> >>*Portlet Decoration* (or skin)
> >>A Portlet Decoration supplies a css style and optionally image references to be used by a Portlet Decorator.
> >
> > This already taken care of by the portlet decorator. Are we going to
> > separate the 2 now? I think I like that idea as it makes development of
> > decorators/decorations that much more complicated
> Scott, I'm not sure I get what you are saying.
>
> Could you please choose only ;-) one below:
> a) you like the separation because it will make development more complicated
> b) you like the separation because otherwise the development will be more complicated
> c) you don't like the separation because it will make development more complicated
> d) you don't like the separation because otherwise the development will be more complicated
>
>
> > I am very against extensive meta-data for folders. Plus, there should
> > be no "id" required for a folder as it is already uniquely identified by
> > its root-relative path.
> +1.
>
> I'm against extensive meta-data too. This is just a first shot of an example in which I wanted to show all
> the options. I should have know this would send the wrong message without explaining it as such.
> Also, this proposal is meant as food for discussion.
> I'm not stuck to this design, I just happen to like it.
> Meta-data configuration is mostly implementation level too me. We should be able to come to an
> agreement on that afterwards. The main design concepts should first be agreed upon.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
Scott T Weaver wrote:
>>*Menu Decorator*
>>A Menu Decorator is used by a Page Decorator to do the actual rendering of a menu. Depending on the Page Decorator
>>capabilities, zero, one or more menus may be rendered on a Page. A Page Decorator could support a top tab menu and
>>a left tree menu for instance.
>
> I just want to make a point that this should not be a java class but a
> simple template fragment.
+1
>>Additionally, a Folder can be configured to be skipped for current level determination. Those Folders are traversed for
>>menu rendering but not included by it (nor its non-Folder elements). For instance the Folders used by the
>>Profiler to find a matching Page (e.g. client capability Folders as wml or html, language Folders as en, fr, nl) could
>>be skipped.
>
> I think there should be support automatically skipped folders like those
> associated with l10n and content type.
+1. It would lead to tight coupling with the Profiler though I guess...
>
>>*Page Decoration* (or skin)
>>A Page Decoration supplies a css style and optionally image references to be used by a Page Decorator.
>>Furthermore, a Page Decoration can supply default css styles and optionally image references to be used by Menu
>>Decorators and Portlet Decorators.
>>
>>*Menu Decoration* (or skin)
>>A Menu Decoration supplies a css style and optionally image references to be used by a Menu Decorator.
>
> I think we should just stick with the page decoration controlling this.
It's already optional :-)
I described for the Page Decoration that it can contain defaults for both the Menu and Portlet decorators (see above).
Its not uncommon that menus look quite differently from the rest of a page. Being able to change only the Menu styles
would be a nice feature (especially for end users) I think.
But, its not a requirement on my side. If we don't like it: drop it.
>
>
>>*Portlet Decoration* (or skin)
>>A Portlet Decoration supplies a css style and optionally image references to be used by a Portlet Decorator.
>
> This already taken care of by the portlet decorator. Are we going to
> separate the 2 now? I think I like that idea as it makes development of
> decorators/decorations that much more complicated
Scott, I'm not sure I get what you are saying.
Could you please choose only ;-) one below:
a) you like the separation because it will make development more complicated
b) you like the separation because otherwise the development will be more complicated
c) you don't like the separation because it will make development more complicated
d) you don't like the separation because otherwise the development will be more complicated
> I am very against extensive meta-data for folders. Plus, there should
> be no "id" required for a folder as it is already uniquely identified by
> its root-relative path.
+1.
I'm against extensive meta-data too. This is just a first shot of an example in which I wanted to show all
the options. I should have know this would send the wrong message without explaining it as such.
Also, this proposal is meant as food for discussion.
I'm not stuck to this design, I just happen to like it.
Meta-data configuration is mostly implementation level too me. We should be able to come to an
agreement on that afterwards. The main design concepts should first be agreed upon.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
On Tue, 2004-06-22 at 13:58, Ate Douma wrote:
> After the long discussion we already had in this thread, I've tried to capture all the comments to get to a Menu (and
> Folder) implementation design which you find below.
>
> I also added a few enhancements (decorator/decoration inheritance and overrides) myself.
> All in all it has become a quite long proposal in which I tried to pin down most issues I could think of.
> I don't expect to have covered all correctly yet though, and maybe I just got it plain wrong :-)
> But, this is how I now see it.
>
> Hopefully this clear things up a bit though and I hope it provides enough food for a continued discussion.
> Lets get this thing nailed down soon!
>
> Regards, Ate
> ------------------------------------------------------------------------------------------------------------------------
> *Folder*
> A Folder is an aggregate of Pages, Folders and Links. It is not viewable or renderable but only used to group its
> elements in an ordered manner. Its elements all have a parent reference to their containing Folder.
> The Folder structure and hierarchy is the basis for Page navigation, layout, decoration and Menu rendering.
> There is only one root Folder without parent. That simplifies the definition of default Decorators and Decorations.
>
> *Folder elements*
> A Folder element (Page, Folder, Link) is defined within it or may be a reference to a element defined in another Folder
> (like Unix symbolic links), which may be a reference in itself.
>
> Deleting an element will result in references defined to become invalid.
>
> Elements which are a reference to another Element defined in another Folder will have as parent the Folder containing
> them. For referenced Folder elements though, its elements will still have as parent the referenced Folder itself, not
> the Folder reference. This means that navigating to an element within a referenced Folder will result in a change of the
> parent hierarchy.
>
> *Page*
> A Page is an aggregate of Fragments and Page configuration. A Page is always used for rendering the end result to the
> user. The Page used is determined by the Profiler based on the client capabilities, navigation parameters and/or request
> parameters.
>
> When a Page is rendered all of its Fragments are rendered for as far as allowed based on possible security
> constraints. It is not possible to reference a single Fragment on a Page for rendering (or possibly using a different
> pipeline).
>
> *Fragment*
> A Fragment is a markup definition for content to be rendered by a portlet. Two types are supported:
> layout and portlet. A layout Fragment definition contains nested Fragments to be layout by it 'layout' portlet. A
> portlet Fragment cannot contain nested Fragments.
>
> Instead of a concrete Fragment definition it is possible to reference another Fragment defined within the Page or from
> another Page. External Fragment references are 'included' during rendering and become part of the Page including them
> and only the decoration and layout configurations from this Page apply.
>
> *Link*
> A Link is a reference to an external url to be displayed in a menu.
>
> *Page Decorator*
> A Page Decorator renders the border (including header and footer) and possibly one or more menus around the Page content
> as well as the layout of the Fragments output from a Page (e.g. column or row wise, single/maximized).
> Menu rendering (if supported) is delegated by the Page Decorator to a Menu Decorator. If more than one menu is supported
> a Menu Decorator must be defined for each. Also, explicitly suppressing the rendering of one or more menus must be
> possible.
>
> *Menu Decorator*
> A Menu Decorator is used by a Page Decorator to do the actual rendering of a menu. Depending on the Page Decorator
> capabilities, zero, one or more menus may be rendered on a Page. A Page Decorator could support a top tab menu and
> a left tree menu for instance.
I just want to make a point that this should not be a java class but a
simple template fragment.
>
> A menu displays Folder elements as navigation links from the current Page. Normally, the current Page, or its first
> parent within the menu will be marked.
>
> Two *root* Folder relative parameters control which Folder elements are to be displayed in the menu: depth and level.
> The level parameter specifies from which level down in the Folder hierarchy the menu rendering should start.
> Minimum value: 1.
> The depth parameter specifies how many levels the menu rendering may continue. Minimum value: 0, indicating all
> remaining levels (useful for tree menus).
>
> Optionally, each Folder element can be configured to be excluded from menu rendering.
>
> Additionally, a Folder can be configured to be skipped for current level determination. Those Folders are traversed for
> menu rendering but not included by it (nor its non-Folder elements). For instance the Folders used by the
> Profiler to find a matching Page (e.g. client capability Folders as wml or html, language Folders as en, fr, nl) could
> be skipped.
I think there should be support automatically skipped folders like those
associated with l10n and content type.
>
> *Portlet Decorator*
> A Portlet Decorator is used for rendering the markup around a portlet Fragment output.
>
> *Decorator lookup*
> Each of the above decorators can be defined within a Page definition, be inherited from the containing Folder or even
> from higher up in the Folder hierarchy. A Portlet Decorator may also be defined on a portlet Fragment within a Page.
> The nearest definition will be used.
> As fallback the *root* Folder shall have a default configuration for each of these (including default menu parameters).
>
> *Page Decoration* (or skin)
> A Page Decoration supplies a css style and optionally image references to be used by a Page Decorator.
> Furthermore, a Page Decoration can supply default css styles and optionally image references to be used by Menu
> Decorators and Portlet Decorators.
>
> *Menu Decoration* (or skin)
> A Menu Decoration supplies a css style and optionally image references to be used by a Menu Decorator.
I think we should just stick with the page decoration controlling this.
>
> *Portlet Decoration* (or skin)
> A Portlet Decoration supplies a css style and optionally image references to be used by a Portlet Decorator.
This already taken care of by the portlet decorator. Are we going to
separate the 2 now? I think I like that idea as it makes development of
decorators/decorations that much more complicated
>
> *Example Folder configuration*
>
> <folder id="subfolder16" description="Sub folder 16" skip="false">
>
> <!-- The value attribute in the decorator definitions below reference a parent variable to which
> the decorator must be assigned.
> As an example the below page definition can be programmed as:
>
> folder.setPageDecorator("default", pageDecorator);
> -->
> <decorator id="jetspeed" type="page" value="default" decoration="jetspeed-blue">
>
> <!-- specify as default topmenu menu decorator a pulldownmenu with an marine menu decoration -->
> <decorator id="pulldownmenu" type="menu" value="topmenu" decoration="marine"/>
>
> <!-- override the default decoration on the leftmenu menu decorator for this folder -->
> <decorator type="menu" value="leftmenu" decoration="yellow"/>
>
> <!-- default disable the rightmenu decorator for this folder -->
> <decorator type="menu" value="rightmenu" disabled="true"/>
>
> <!-- specify as default portlet decorator the jetspeed portlet decorator with jetspeed-blue decoration-->
> <decorator id="jetspeed" type="portlet" value="default" decoration="jetspeed-blue"/>
> </decorator>
>
> <!-- menu parameters -->
> <menu id="tabmenu" level="1" depth="2"/>
> <menu id="treemenu" level="3" depth="0"/>
>
> <!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
> in the order as defined
> -->
> <elements>
>
> <page id="page1" description="Page 1"/>
> <page ref="../../subfolder2/page8"/>
> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>
> <folder id="subfolder1"/>
> <folder ref="/subfolder1/subfolder3"/>
>
> <link url="http://www.apache.org" description="Home Apache" target="_self"/>
> <link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
>
> <!-- hidden elements -->
> <page id="page2" hidden="true"/>
> <folder id="subfolder2" hidden="true"/>
>
> </elements>
>
> </folder>
I am very against extensive meta-data for folders. Plus, there should
be no "id" required for a folder as it is already uniquely identified by
its root-relative path.
> -------------------------------------------------------------------------------------------------------------------------
>
>
> Ate Douma wrote:
>
> > I've been trying to get a clear picture of what the options and
> > positions are about menu creation for J2.
> >
> > I'm quite lost after reviewing several sources:
> > - 1) current J1 impl
> > - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
> > - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
> > ([J2} Proposal for Layout, pages & Decorator handling in J2)
> > - 4) http://nagoya.apache.org/jira/browse/JS2-69
> > (Finalizing Portal Navigation using the Profiler)
> >
> > A few design issues needs to be addressed I think to be able to decide
> > on the impl. of menus.
> >
> > - Nested pages
> > Should these be allowed?
> > Part of that question is what a Page is.
> > The pdf (see 2) says its to be considered a Fragment.
> > If this is meant as a "fragment" which can be included, alright. But, I
> > don't see how it also can
> > be a "Fragment" (note the case) or why it should be made one.
> >
> > Fragments already can contain other Fragments though. This is more or
> > less in analogy to nested
> > portlets in J1 I belief.
> >
> > Maybe one reason why one would want to nest pages is to be able to
> > define different decoration on a nested page.
> > It has been suggested by Scott (see 4) to allow for the most flexible
> > way possible this should be possible
> > (even up/down overrides if needed).
> >
> > To me, this seems to lead to very complex psml though. I would certainly
> > like to see a more
> > simple model implemented first before going that road.
> >
> > Probably the same result could be created without page nesting using
> > fragment references. These could
> > reference other pages (pulling in their decorator definitions with them)
> > or fragments within other pages.
> > As far as I can tell, then there would be no need to define pages within
> > pages.
> >
> > - Folder or menu elements
> > The Folder concept containing other folders and/or pages could be used
> > to generate menus as proposed by Scott (see 4).
> > Something I'm missing right now is a clear understanding how/where
> > folders are defined. I found the om impl but no usage
> > yet so its something I can't relate to enough yet to really decide if
> > I'm going to like it or not.
> >
> > One important issue I would have with it though is that it wouldn't
> > allow me to render page fragments/portlets in a menu, not external links.
> > Likewise, I don't see how a TabbedPane could be rendered for the current
> > page using the folder
> > concept.
> >
> > The other proposal from David Taylor was defining new psml menu and
> > menu-item elements which could reference pages, (external) fragments and
> > external links (see 3).
> > I understand Scott didn't like adding additional data structures into
> > the mix (see 4), but I for one would prefer this
> > above the folder/page -> menu concept. AFAIK its way more flexible and
> > probably much easier to understand for a user.
> > And, it isn't that different from the J1 implementation. Recreating the
> > current J1 features for J2 will be relatively easier to do I think.
> >
> > Note: I know the folder concept is not *just* about menus. I'm not
> > opposed to folders in anyway. I just think its
> > to restricted for menu rendering.
> >
> > I'd like some comments and if already possible a vote which way we
> > should go about menu rendering.
> > I know I'll something soon ;-)
> >
> > Regards,
> >
> > Ate
> >
> >
> > ---------------------------------------------------------------------
> > 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
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Serge Huber <sh...@jahia.com>.
At 11:46 23.06.2004, you wrote:
>In the form module we are building we have our field-labels and button
>captions in the localization resource file, and in the xml definition we
>place the resource identifier for each field or button. Then, in the init
>phase of the form, we lookup all the translated labels and captions using
>the resource identifiers. It works lika a charm.
Yes I also believe that is a good way of doing it, but I was wondering if
Ate had already come up with something. Usually the way I do it is
something like this :
<page description="Home page" descriptionKey="homePageKey">
descriptionKey could be optional, etc... I believe this is the way that the
Struts Taglib also does things.
Regards,
Serge Huber.
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Stijn de Witt <St...@bergland-it.nl>.
----- Original Message -----
From: "Serge Huber" <sh...@jahia.com>
To: "Jetspeed Developers List" <je...@jakarta.apache.org>
Sent: Wednesday, June 23, 2004 11:04 AM
Subject: Re: [J2] Menu implementation
<SNIP>
> > <!-- Folder elements displayed in the menu (in the current example
in
> > tabmenu if level < 3 or in treemenu otherwise)
> > in the order as defined
> > -->
> > <elements>
> >
> > <page id="page1" description="Page 1"/>
> > <page ref="../../subfolder2/page8"/>
> > <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
> >
> > <folder id="subfolder1"/>
> > <folder ref="/subfolder1/subfolder3"/>
> >
> > <link url="http://www.apache.org" description="Home
> > Apache" target="_self"/>
> > <link url="http://portals.apache.org" description="Home Apache
> > Portals" target="outside"/>
> >
> > <!-- hidden elements -->
> > <page id="page2" hidden="true"/>
> > <folder id="subfolder2" hidden="true"/>
> >
> > </elements>
> >
> > </folder>
>
> Thanks for the example, it always helps to clear things up ! One question
> again : how would this be internationalized ? Are descriptions used to be
> displayed ? If so, how do you specify descriptions for other languages ?
>
> Regards,
> Serge Huber.
>
In the form module we are building we have our field-labels and button
captions in the localization resource file, and in the xml definition we
place the resource identifier for each field or button. Then, in the init
phase of the form, we lookup all the translated labels and captions using
the resource identifiers. It works lika a charm.
-Stijn
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
Serge Huber wrote:
>
> Hi Ate,
>
> Thanks for all this, it definitely helps clear out some definitions that
> haven't been very clear in my mind. I have a few questions and remarks,
> that you can find below...
>
> At 19:58 22.06.2004, you wrote:
>
>> --
>> *Folder*
>> A Folder is an aggregate of Pages, Folders and Links. It is not
>> viewable or renderable but only used to group its
>> elements in an ordered manner. Its elements all have a parent
>> reference to their containing Folder.
>> The Folder structure and hierarchy is the basis for Page navigation,
>> layout, decoration and Menu rendering.
>> There is only one root Folder without parent. That simplifies the
>> definition of default Decorators and Decorations.
>
>
> When you say a folder is not renderable, you mean it's content is never
> shown as per say, and it doesn't have any decorator, but it does appear
> in the menu right ?
I might be rendered with a different pipeline (a folder/page browser pipeline for instance)
but not using the 'normal' portal pipeline.
In a menu its description will be displayed if, and only if it contains
elements which also must be displayed. It then represents a menu node of
the menu tree. Only Pages and Links are to be displayed as leafs.
>
>
>> *Folder elements*
>> A Folder element (Page, Folder, Link) is defined within it or may be a
>> reference to a element defined in another Folder
>> (like Unix symbolic links), which may be a reference in itself.
>>
>> Deleting an element will result in references defined to become invalid.
>>
>> Elements which are a reference to another Element defined in another
>> Folder will have as parent the Folder containing
>> them. For referenced Folder elements though, its elements will still
>> have as parent the referenced Folder itself, not
>> the Folder reference. This means that navigating to an element within
>> a referenced Folder will result in a change of the
>> parent hierarchy.
>
>
> How would symbolic links work ? Could they survive folder moving ? (not
> deleting but moving) ? One of the problems of using hierarchical
> structures is maintaining integrity when using links (that are actually
> artifacts to bypass the hierarchic structure). In a more general way,
> could we move folders and or folder elements around ?
Depends on the implementation how easy that can be supported. With a database
implementation references probably can easily be updated. In a CMS store
probably too.
With a plain file system implementation it can only be done properly using a fancy
gui customizer (webbased).
I think any design supporting symbolic links will have the same problem though.
Not only a hierarchic model and especially filesystem based implementations.
>
>
>> <!-- Folder elements displayed in the menu (in the current example
>> in tabmenu if level < 3 or in treemenu otherwise)
>> in the order as defined
>> -->
>> <elements>
>>
>> <page id="page1" description="Page 1"/>
>> <page ref="../../subfolder2/page8"/>
>> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>>
>> <folder id="subfolder1"/>
>> <folder ref="/subfolder1/subfolder3"/>
>>
>> <link url="http://www.apache.org" description="Home
>> Apache" target="_self"/>
>> <link url="http://portals.apache.org" description="Home Apache
>> Portals" target="outside"/>
>>
>> <!-- hidden elements -->
>> <page id="page2" hidden="true"/>
>> <folder id="subfolder2" hidden="true"/>
>>
>> </elements>
>>
>> </folder>
>
>
> Thanks for the example, it always helps to clear things up ! One
> question again : how would this be internationalized ? Are descriptions
> used to be displayed ? If so, how do you specify descriptions for other
> languages ?
There are a few options I think. Note: I didn't try yet to specify a complete
design. There are still issues to address like integration with the Profiler.
The Profiler could handle language and media type resolution using separate folders
like it is now in J1):
folder1
subfolder2
html
en
page1
de
page1
wml
en
page1
de
page1
Note: those 'profiler' folders can be automatically skipped (using a skip attribute on those
type of folders) for level determination and rendering.
Besides using the Profiler one could allow for locale support in nested description elements:
<page id="page1">
<description lang="en">Page 1</description>
<description lang="de">Seite 1</description>
</link>
Finally, localized resource bundles can be used and then resource identifiers are specified
in the configuration instead of hard coded values. At runtime the correct, localized description
can then be looked up.
>
> Regards,
> Serge Huber.
>
>
> - -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
> www.jahia.org : A collaborative source CMS and Portal Server
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Serge Huber <sh...@jahia.com>.
Hi Ate,
Thanks for all this, it definitely helps clear out some definitions that
haven't been very clear in my mind. I have a few questions and remarks,
that you can find below...
At 19:58 22.06.2004, you wrote:
>--
>*Folder*
>A Folder is an aggregate of Pages, Folders and Links. It is not viewable
>or renderable but only used to group its
>elements in an ordered manner. Its elements all have a parent reference to
>their containing Folder.
>The Folder structure and hierarchy is the basis for Page navigation,
>layout, decoration and Menu rendering.
>There is only one root Folder without parent. That simplifies the
>definition of default Decorators and Decorations.
When you say a folder is not renderable, you mean it's content is never
shown as per say, and it doesn't have any decorator, but it does appear in
the menu right ?
>*Folder elements*
>A Folder element (Page, Folder, Link) is defined within it or may be a
>reference to a element defined in another Folder
>(like Unix symbolic links), which may be a reference in itself.
>
>Deleting an element will result in references defined to become invalid.
>
>Elements which are a reference to another Element defined in another
>Folder will have as parent the Folder containing
>them. For referenced Folder elements though, its elements will still have
>as parent the referenced Folder itself, not
>the Folder reference. This means that navigating to an element within a
>referenced Folder will result in a change of the
>parent hierarchy.
How would symbolic links work ? Could they survive folder moving ? (not
deleting but moving) ? One of the problems of using hierarchical structures
is maintaining integrity when using links (that are actually artifacts to
bypass the hierarchic structure). In a more general way, could we move
folders and or folder elements around ?
> <!-- Folder elements displayed in the menu (in the current example in
> tabmenu if level < 3 or in treemenu otherwise)
> in the order as defined
> -->
> <elements>
>
> <page id="page1" description="Page 1"/>
> <page ref="../../subfolder2/page8"/>
> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>
> <folder id="subfolder1"/>
> <folder ref="/subfolder1/subfolder3"/>
>
> <link url="http://www.apache.org" description="Home
> Apache" target="_self"/>
> <link url="http://portals.apache.org" description="Home Apache
> Portals" target="outside"/>
>
> <!-- hidden elements -->
> <page id="page2" hidden="true"/>
> <folder id="subfolder2" hidden="true"/>
>
> </elements>
>
> </folder>
Thanks for the example, it always helps to clear things up ! One question
again : how would this be internationalized ? Are descriptions used to be
displayed ? If so, how do you specify descriptions for other languages ?
Regards,
Serge Huber.
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Stijn de Witt <St...@bergland-it.nl>.
----- Original Message -----
From: "David Sean Taylor" <da...@bluesunrise.com>
To: "Jetspeed Developers List" <je...@jakarta.apache.org>
Sent: Wednesday, June 23, 2004 4:56 AM
Subject: Re: [J2] Menu implementation
>
> On Jun 22, 2004, at 3:21 PM, Stijn de Witt wrote:
>
> > Hi,
> >
> > I've been watching this thread and I would like to point out an
> > 'issue' with
> > Jetspeed 1, that I hope can be circumvented in Jetspeed 2.
> >
> > In Jetspeed 1, the URL shown in the addressbar can NOT always take you
> > back
> > to that page later. This means that, if you are on page A and copy the
> > address in the addressbar, and then you navigate to page B and paste
> > the URL
> > and click GO, sometimes, this will NOT take you back to page A!
> Jetspeed Pane menus have had this limitation for a long time.
> Menu state is stored in the session.
> I tried to address this by creating a generalized way of accessing the
> portlet via JetspeedLink
> JetspeedLink (and JetspeedForwards) both create URLs than can be
> bookmarked, including submenus
> The next step was to integrate menus with Links and Forwards, but I
> never completed it
>
Ah ok. Great to know that you guys are aware of this.
Thanks for all your hard work!
With kind regards,
-Stijn
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jun 22, 2004, at 3:21 PM, Stijn de Witt wrote:
> Hi,
>
> I've been watching this thread and I would like to point out an
> 'issue' with
> Jetspeed 1, that I hope can be circumvented in Jetspeed 2.
>
> In Jetspeed 1, the URL shown in the addressbar can NOT always take you
> back
> to that page later. This means that, if you are on page A and copy the
> address in the addressbar, and then you navigate to page B and paste
> the URL
> and click GO, sometimes, this will NOT take you back to page A!
>
Jetspeed Pane menus have had this limitation for a long time.
Menu state is stored in the session.
I tried to address this by creating a generalized way of accessing the
portlet via JetspeedLink
JetspeedLink (and JetspeedForwards) both create URLs than can be
bookmarked, including submenus
The next step was to integrate menus with Links and Forwards, but I
never completed it
> Try it, nest a menupane inside a tabpane, then select any page in the
> menu
> other than the default and copy the link. Navigate to another page in
> the
> menu, then to another tab. Now paste the link and hit GO... It will
> take you
> to the default page of the menu instead of the one you were on
> before...
>
> With kind regards,
>
> Stijn de Witt
>
>
>
> ----- Original Message -----
> From: "Ate Douma" <at...@douma.nu>
> To: "Jetspeed Developers List" <je...@jakarta.apache.org>
> Sent: Tuesday, June 22, 2004 7:58 PM
> Subject: Re: [J2] Menu implementation
>
>
>> After the long discussion we already had in this thread, I've tried to
> capture all the comments to get to a Menu (and
>> Folder) implementation design which you find below.
>>
>> I also added a few enhancements (decorator/decoration inheritance and
> overrides) myself.
>> All in all it has become a quite long proposal in which I tried to pin
> down most issues I could think of.
>> I don't expect to have covered all correctly yet though, and maybe I
>> just
> got it plain wrong :-)
>> But, this is how I now see it.
>>
>> Hopefully this clear things up a bit though and I hope it provides
>> enough
> food for a continued discussion.
>> Lets get this thing nailed down soon!
>>
>> Regards, Ate
>> ----------------------------------------------------------------------
>> ----
> ----------------------------------------------
>> *Folder*
>> A Folder is an aggregate of Pages, Folders and Links. It is not
>> viewable
> or renderable but only used to group its
>> elements in an ordered manner. Its elements all have a parent
>> reference to
> their containing Folder.
>> The Folder structure and hierarchy is the basis for Page navigation,
> layout, decoration and Menu rendering.
>> There is only one root Folder without parent. That simplifies the
> definition of default Decorators and Decorations.
>>
>> *Folder elements*
>> A Folder element (Page, Folder, Link) is defined within it or may be a
> reference to a element defined in another Folder
>> (like Unix symbolic links), which may be a reference in itself.
>>
>> Deleting an element will result in references defined to become
>> invalid.
>>
>> Elements which are a reference to another Element defined in another
> Folder will have as parent the Folder containing
>> them. For referenced Folder elements though, its elements will still
>> have
> as parent the referenced Folder itself, not
>> the Folder reference. This means that navigating to an element within
>> a
> referenced Folder will result in a change of the
>> parent hierarchy.
>>
>> *Page*
>> A Page is an aggregate of Fragments and Page configuration. A Page is
> always used for rendering the end result to the
>> user. The Page used is determined by the Profiler based on the client
> capabilities, navigation parameters and/or request
>> parameters.
>>
>> When a Page is rendered all of its Fragments are rendered for as far
>> as
> allowed based on possible security
>> constraints. It is not possible to reference a single Fragment on a
>> Page
> for rendering (or possibly using a different
>> pipeline).
>>
>> *Fragment*
>> A Fragment is a markup definition for content to be rendered by a
>> portlet.
> Two types are supported:
>> layout and portlet. A layout Fragment definition contains nested
>> Fragments
> to be layout by it 'layout' portlet. A
>> portlet Fragment cannot contain nested Fragments.
>>
>> Instead of a concrete Fragment definition it is possible to reference
> another Fragment defined within the Page or from
>> another Page. External Fragment references are 'included' during
>> rendering
> and become part of the Page including them
>> and only the decoration and layout configurations from this Page
>> apply.
>>
>> *Link*
>> A Link is a reference to an external url to be displayed in a menu.
>>
>> *Page Decorator*
>> A Page Decorator renders the border (including header and footer) and
> possibly one or more menus around the Page content
>> as well as the layout of the Fragments output from a Page (e.g.
>> column or
> row wise, single/maximized).
>> Menu rendering (if supported) is delegated by the Page Decorator to a
>> Menu
> Decorator. If more than one menu is supported
>> a Menu Decorator must be defined for each. Also, explicitly
>> suppressing
> the rendering of one or more menus must be
>> possible.
>>
>> *Menu Decorator*
>> A Menu Decorator is used by a Page Decorator to do the actual
>> rendering of
> a menu. Depending on the Page Decorator
>> capabilities, zero, one or more menus may be rendered on a Page. A
>> Page
> Decorator could support a top tab menu and
>> a left tree menu for instance.
>>
>> A menu displays Folder elements as navigation links from the current
>> Page.
> Normally, the current Page, or its first
>> parent within the menu will be marked.
>>
>> Two *root* Folder relative parameters control which Folder elements
>> are to
> be displayed in the menu: depth and level.
>> The level parameter specifies from which level down in the Folder
> hierarchy the menu rendering should start.
>> Minimum value: 1.
>> The depth parameter specifies how many levels the menu rendering may
> continue. Minimum value: 0, indicating all
>> remaining levels (useful for tree menus).
>>
>> Optionally, each Folder element can be configured to be excluded from
>> menu
> rendering.
>>
>> Additionally, a Folder can be configured to be skipped for current
>> level
> determination. Those Folders are traversed for
>> menu rendering but not included by it (nor its non-Folder elements).
>> For
> instance the Folders used by the
>> Profiler to find a matching Page (e.g. client capability Folders as
>> wml or
> html, language Folders as en, fr, nl) could
>> be skipped.
>>
>> *Portlet Decorator*
>> A Portlet Decorator is used for rendering the markup around a portlet
> Fragment output.
>>
>> *Decorator lookup*
>> Each of the above decorators can be defined within a Page definition,
>> be
> inherited from the containing Folder or even
>> from higher up in the Folder hierarchy. A Portlet Decorator may also
>> be
> defined on a portlet Fragment within a Page.
>> The nearest definition will be used.
>> As fallback the *root* Folder shall have a default configuration for
>> each
> of these (including default menu parameters).
>>
>> *Page Decoration* (or skin)
>> A Page Decoration supplies a css style and optionally image
>> references to
> be used by a Page Decorator.
>> Furthermore, a Page Decoration can supply default css styles and
> optionally image references to be used by Menu
>> Decorators and Portlet Decorators.
>>
>> *Menu Decoration* (or skin)
>> A Menu Decoration supplies a css style and optionally image
>> references to
> be used by a Menu Decorator.
>>
>> *Portlet Decoration* (or skin)
>> A Portlet Decoration supplies a css style and optionally image
>> references
> to be used by a Portlet Decorator.
>>
>> *Example Folder configuration*
>>
>> <folder id="subfolder16" description="Sub folder 16" skip="false">
>>
>> <!-- The value attribute in the decorator definitions below
>> reference
> a parent variable to which
>> the decorator must be assigned.
>> As an example the below page definition can be programmed
>> as:
>>
>> folder.setPageDecorator("default", pageDecorator);
>> -->
>> <decorator id="jetspeed" type="page" value="default"
> decoration="jetspeed-blue">
>>
>> <!-- specify as default topmenu menu decorator a pulldownmenu
>> with
> an marine menu decoration -->
>> <decorator id="pulldownmenu" type="menu" value="topmenu"
> decoration="marine"/>
>>
>> <!-- override the default decoration on the leftmenu menu
>> decorator
> for this folder -->
>> <decorator type="menu" value="leftmenu"
> decoration="yellow"/>
>>
>> <!-- default disable the rightmenu decorator for this folder
>> -->
>> <decorator type="menu" value="rightmenu"
> disabled="true"/>
>>
>> <!-- specify as default portlet decorator the jetspeed portlet
> decorator with jetspeed-blue decoration-->
>> <decorator id="jetspeed" type="portlet" value="default"
> decoration="jetspeed-blue"/>
>> </decorator>
>>
>> <!-- menu parameters -->
>> <menu id="tabmenu" level="1" depth="2"/>
>> <menu id="treemenu" level="3" depth="0"/>
>>
>> <!-- Folder elements displayed in the menu (in the current
>> example in
> tabmenu if level < 3 or in treemenu otherwise)
>> in the order as defined
>> -->
>> <elements>
>>
>> <page id="page1" description="Page 1"/>
>> <page ref="../../subfolder2/page8"/>
>> <page ref="/subfolder1/subfolder2/page9" description="Page 9"
>> />
>>
>> <folder id="subfolder1"/>
>> <folder ref="/subfolder1/subfolder3"/>
>>
>> <link url="http://www.apache.org" description="Home Apache"
> target="_self"/>
>> <link url="http://portals.apache.org" description="Home Apache
> Portals" target="outside"/>
>>
>> <!-- hidden elements -->
>> <page id="page2" hidden="true"/>
>> <folder id="subfolder2" hidden="true"/>
>>
>> </elements>
>>
>> </folder>
>> ----------------------------------------------------------------------
>> ----
> -----------------------------------------------
>>
>>
>> Ate Douma wrote:
>>
>>> I've been trying to get a clear picture of what the options and
>>> positions are about menu creation for J2.
>>>
>>> I'm quite lost after reviewing several sources:
>>> - 1) current J1 impl
>>> - 2) design-docs/src/decorations/J2 layout and decorator
>>> handling.pdf,
>>> - 3)
>>> http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
>>> ([J2} Proposal for Layout, pages & Decorator handling in J2)
>>> - 4) http://nagoya.apache.org/jira/browse/JS2-69
>>> (Finalizing Portal Navigation using the Profiler)
>>>
>>> A few design issues needs to be addressed I think to be able to
>>> decide
>>> on the impl. of menus.
>>>
>>> - Nested pages
>>> Should these be allowed?
>>> Part of that question is what a Page is.
>>> The pdf (see 2) says its to be considered a Fragment.
>>> If this is meant as a "fragment" which can be included, alright.
>>> But, I
>>> don't see how it also can
>>> be a "Fragment" (note the case) or why it should be made one.
>>>
>>> Fragments already can contain other Fragments though. This is more or
>>> less in analogy to nested
>>> portlets in J1 I belief.
>>>
>>> Maybe one reason why one would want to nest pages is to be able to
>>> define different decoration on a nested page.
>>> It has been suggested by Scott (see 4) to allow for the most flexible
>>> way possible this should be possible
>>> (even up/down overrides if needed).
>>>
>>> To me, this seems to lead to very complex psml though. I would
>>> certainly
>>> like to see a more
>>> simple model implemented first before going that road.
>>>
>>> Probably the same result could be created without page nesting using
>>> fragment references. These could
>>> reference other pages (pulling in their decorator definitions with
>>> them)
>>> or fragments within other pages.
>>> As far as I can tell, then there would be no need to define pages
>>> within
>>> pages.
>>>
>>> - Folder or menu elements
>>> The Folder concept containing other folders and/or pages could be
>>> used
>>> to generate menus as proposed by Scott (see 4).
>>> Something I'm missing right now is a clear understanding how/where
>>> folders are defined. I found the om impl but no usage
>>> yet so its something I can't relate to enough yet to really decide if
>>> I'm going to like it or not.
>>>
>>> One important issue I would have with it though is that it wouldn't
>>> allow me to render page fragments/portlets in a menu, not external
> links.
>>> Likewise, I don't see how a TabbedPane could be rendered for the
>>> current
>>> page using the folder
>>> concept.
>>>
>>> The other proposal from David Taylor was defining new psml menu and
>>> menu-item elements which could reference pages, (external) fragments
>>> and
>>> external links (see 3).
>>> I understand Scott didn't like adding additional data structures into
>>> the mix (see 4), but I for one would prefer this
>>> above the folder/page -> menu concept. AFAIK its way more flexible
>>> and
>>> probably much easier to understand for a user.
>>> And, it isn't that different from the J1 implementation. Recreating
>>> the
>>> current J1 features for J2 will be relatively easier to do I think.
>>>
>>> Note: I know the folder concept is not *just* about menus. I'm not
>>> opposed to folders in anyway. I just think its
>>> to restricted for menu rendering.
>>>
>>> I'd like some comments and if already possible a vote which way we
>>> should go about menu rendering.
>>> I know I'll something soon ;-)
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
--
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
Re: [J2] Menu implementation
Posted by Stijn de Witt <St...@bergland-it.nl>.
Hi,
I've been watching this thread and I would like to point out an 'issue' with
Jetspeed 1, that I hope can be circumvented in Jetspeed 2.
In Jetspeed 1, the URL shown in the addressbar can NOT always take you back
to that page later. This means that, if you are on page A and copy the
address in the addressbar, and then you navigate to page B and paste the URL
and click GO, sometimes, this will NOT take you back to page A!
Try it, nest a menupane inside a tabpane, then select any page in the menu
other than the default and copy the link. Navigate to another page in the
menu, then to another tab. Now paste the link and hit GO... It will take you
to the default page of the menu instead of the one you were on before...
With kind regards,
Stijn de Witt
----- Original Message -----
From: "Ate Douma" <at...@douma.nu>
To: "Jetspeed Developers List" <je...@jakarta.apache.org>
Sent: Tuesday, June 22, 2004 7:58 PM
Subject: Re: [J2] Menu implementation
> After the long discussion we already had in this thread, I've tried to
capture all the comments to get to a Menu (and
> Folder) implementation design which you find below.
>
> I also added a few enhancements (decorator/decoration inheritance and
overrides) myself.
> All in all it has become a quite long proposal in which I tried to pin
down most issues I could think of.
> I don't expect to have covered all correctly yet though, and maybe I just
got it plain wrong :-)
> But, this is how I now see it.
>
> Hopefully this clear things up a bit though and I hope it provides enough
food for a continued discussion.
> Lets get this thing nailed down soon!
>
> Regards, Ate
> --------------------------------------------------------------------------
----------------------------------------------
> *Folder*
> A Folder is an aggregate of Pages, Folders and Links. It is not viewable
or renderable but only used to group its
> elements in an ordered manner. Its elements all have a parent reference to
their containing Folder.
> The Folder structure and hierarchy is the basis for Page navigation,
layout, decoration and Menu rendering.
> There is only one root Folder without parent. That simplifies the
definition of default Decorators and Decorations.
>
> *Folder elements*
> A Folder element (Page, Folder, Link) is defined within it or may be a
reference to a element defined in another Folder
> (like Unix symbolic links), which may be a reference in itself.
>
> Deleting an element will result in references defined to become invalid.
>
> Elements which are a reference to another Element defined in another
Folder will have as parent the Folder containing
> them. For referenced Folder elements though, its elements will still have
as parent the referenced Folder itself, not
> the Folder reference. This means that navigating to an element within a
referenced Folder will result in a change of the
> parent hierarchy.
>
> *Page*
> A Page is an aggregate of Fragments and Page configuration. A Page is
always used for rendering the end result to the
> user. The Page used is determined by the Profiler based on the client
capabilities, navigation parameters and/or request
> parameters.
>
> When a Page is rendered all of its Fragments are rendered for as far as
allowed based on possible security
> constraints. It is not possible to reference a single Fragment on a Page
for rendering (or possibly using a different
> pipeline).
>
> *Fragment*
> A Fragment is a markup definition for content to be rendered by a portlet.
Two types are supported:
> layout and portlet. A layout Fragment definition contains nested Fragments
to be layout by it 'layout' portlet. A
> portlet Fragment cannot contain nested Fragments.
>
> Instead of a concrete Fragment definition it is possible to reference
another Fragment defined within the Page or from
> another Page. External Fragment references are 'included' during rendering
and become part of the Page including them
> and only the decoration and layout configurations from this Page apply.
>
> *Link*
> A Link is a reference to an external url to be displayed in a menu.
>
> *Page Decorator*
> A Page Decorator renders the border (including header and footer) and
possibly one or more menus around the Page content
> as well as the layout of the Fragments output from a Page (e.g. column or
row wise, single/maximized).
> Menu rendering (if supported) is delegated by the Page Decorator to a Menu
Decorator. If more than one menu is supported
> a Menu Decorator must be defined for each. Also, explicitly suppressing
the rendering of one or more menus must be
> possible.
>
> *Menu Decorator*
> A Menu Decorator is used by a Page Decorator to do the actual rendering of
a menu. Depending on the Page Decorator
> capabilities, zero, one or more menus may be rendered on a Page. A Page
Decorator could support a top tab menu and
> a left tree menu for instance.
>
> A menu displays Folder elements as navigation links from the current Page.
Normally, the current Page, or its first
> parent within the menu will be marked.
>
> Two *root* Folder relative parameters control which Folder elements are to
be displayed in the menu: depth and level.
> The level parameter specifies from which level down in the Folder
hierarchy the menu rendering should start.
> Minimum value: 1.
> The depth parameter specifies how many levels the menu rendering may
continue. Minimum value: 0, indicating all
> remaining levels (useful for tree menus).
>
> Optionally, each Folder element can be configured to be excluded from menu
rendering.
>
> Additionally, a Folder can be configured to be skipped for current level
determination. Those Folders are traversed for
> menu rendering but not included by it (nor its non-Folder elements). For
instance the Folders used by the
> Profiler to find a matching Page (e.g. client capability Folders as wml or
html, language Folders as en, fr, nl) could
> be skipped.
>
> *Portlet Decorator*
> A Portlet Decorator is used for rendering the markup around a portlet
Fragment output.
>
> *Decorator lookup*
> Each of the above decorators can be defined within a Page definition, be
inherited from the containing Folder or even
> from higher up in the Folder hierarchy. A Portlet Decorator may also be
defined on a portlet Fragment within a Page.
> The nearest definition will be used.
> As fallback the *root* Folder shall have a default configuration for each
of these (including default menu parameters).
>
> *Page Decoration* (or skin)
> A Page Decoration supplies a css style and optionally image references to
be used by a Page Decorator.
> Furthermore, a Page Decoration can supply default css styles and
optionally image references to be used by Menu
> Decorators and Portlet Decorators.
>
> *Menu Decoration* (or skin)
> A Menu Decoration supplies a css style and optionally image references to
be used by a Menu Decorator.
>
> *Portlet Decoration* (or skin)
> A Portlet Decoration supplies a css style and optionally image references
to be used by a Portlet Decorator.
>
> *Example Folder configuration*
>
> <folder id="subfolder16" description="Sub folder 16" skip="false">
>
> <!-- The value attribute in the decorator definitions below reference
a parent variable to which
> the decorator must be assigned.
> As an example the below page definition can be programmed as:
>
> folder.setPageDecorator("default", pageDecorator);
> -->
> <decorator id="jetspeed" type="page" value="default"
decoration="jetspeed-blue">
>
> <!-- specify as default topmenu menu decorator a pulldownmenu with
an marine menu decoration -->
> <decorator id="pulldownmenu" type="menu" value="topmenu"
decoration="marine"/>
>
> <!-- override the default decoration on the leftmenu menu decorator
for this folder -->
> <decorator type="menu" value="leftmenu"
decoration="yellow"/>
>
> <!-- default disable the rightmenu decorator for this folder -->
> <decorator type="menu" value="rightmenu"
disabled="true"/>
>
> <!-- specify as default portlet decorator the jetspeed portlet
decorator with jetspeed-blue decoration-->
> <decorator id="jetspeed" type="portlet" value="default"
decoration="jetspeed-blue"/>
> </decorator>
>
> <!-- menu parameters -->
> <menu id="tabmenu" level="1" depth="2"/>
> <menu id="treemenu" level="3" depth="0"/>
>
> <!-- Folder elements displayed in the menu (in the current example in
tabmenu if level < 3 or in treemenu otherwise)
> in the order as defined
> -->
> <elements>
>
> <page id="page1" description="Page 1"/>
> <page ref="../../subfolder2/page8"/>
> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>
> <folder id="subfolder1"/>
> <folder ref="/subfolder1/subfolder3"/>
>
> <link url="http://www.apache.org" description="Home Apache"
target="_self"/>
> <link url="http://portals.apache.org" description="Home Apache
Portals" target="outside"/>
>
> <!-- hidden elements -->
> <page id="page2" hidden="true"/>
> <folder id="subfolder2" hidden="true"/>
>
> </elements>
>
> </folder>
> --------------------------------------------------------------------------
-----------------------------------------------
>
>
> Ate Douma wrote:
>
> > I've been trying to get a clear picture of what the options and
> > positions are about menu creation for J2.
> >
> > I'm quite lost after reviewing several sources:
> > - 1) current J1 impl
> > - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
> > - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
> > ([J2} Proposal for Layout, pages & Decorator handling in J2)
> > - 4) http://nagoya.apache.org/jira/browse/JS2-69
> > (Finalizing Portal Navigation using the Profiler)
> >
> > A few design issues needs to be addressed I think to be able to decide
> > on the impl. of menus.
> >
> > - Nested pages
> > Should these be allowed?
> > Part of that question is what a Page is.
> > The pdf (see 2) says its to be considered a Fragment.
> > If this is meant as a "fragment" which can be included, alright. But, I
> > don't see how it also can
> > be a "Fragment" (note the case) or why it should be made one.
> >
> > Fragments already can contain other Fragments though. This is more or
> > less in analogy to nested
> > portlets in J1 I belief.
> >
> > Maybe one reason why one would want to nest pages is to be able to
> > define different decoration on a nested page.
> > It has been suggested by Scott (see 4) to allow for the most flexible
> > way possible this should be possible
> > (even up/down overrides if needed).
> >
> > To me, this seems to lead to very complex psml though. I would certainly
> > like to see a more
> > simple model implemented first before going that road.
> >
> > Probably the same result could be created without page nesting using
> > fragment references. These could
> > reference other pages (pulling in their decorator definitions with them)
> > or fragments within other pages.
> > As far as I can tell, then there would be no need to define pages within
> > pages.
> >
> > - Folder or menu elements
> > The Folder concept containing other folders and/or pages could be used
> > to generate menus as proposed by Scott (see 4).
> > Something I'm missing right now is a clear understanding how/where
> > folders are defined. I found the om impl but no usage
> > yet so its something I can't relate to enough yet to really decide if
> > I'm going to like it or not.
> >
> > One important issue I would have with it though is that it wouldn't
> > allow me to render page fragments/portlets in a menu, not external
links.
> > Likewise, I don't see how a TabbedPane could be rendered for the current
> > page using the folder
> > concept.
> >
> > The other proposal from David Taylor was defining new psml menu and
> > menu-item elements which could reference pages, (external) fragments and
> > external links (see 3).
> > I understand Scott didn't like adding additional data structures into
> > the mix (see 4), but I for one would prefer this
> > above the folder/page -> menu concept. AFAIK its way more flexible and
> > probably much easier to understand for a user.
> > And, it isn't that different from the J1 implementation. Recreating the
> > current J1 features for J2 will be relatively easier to do I think.
> >
> > Note: I know the folder concept is not *just* about menus. I'm not
> > opposed to folders in anyway. I just think its
> > to restricted for menu rendering.
> >
> > I'd like some comments and if already possible a vote which way we
> > should go about menu rendering.
> > I know I'll something soon ;-)
> >
> > Regards,
> >
> > Ate
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation (Offtopic)
Posted by Serge Huber <sh...@jahia.com>.
One could be done is that if old browsers don't need to be supported you
could also get rid of <table> tags and do everything with <div> tags (see
http://www.csszengarden.com for examples of this).
As for putting id attributes on all tags that seems ok, but the most
important thing will be the use of classes, are usually your controls will
be marked by class rather than by id (I'm thinking for example about
portlet decorator controls for portlet mode and window state changes).
Regards,
Serge Huber.
At 02:16 24.06.2004, you wrote:
>----- Original Message -----
>From: "Ate Douma" <at...@douma.nu>
>To: "Jetspeed Developers List" <je...@jakarta.apache.org>
>Sent: Tuesday, June 22, 2004 7:58 PM
>Subject: Re: [J2] Menu implementation
>
><SNIP>
>
> > *Page Decoration* (or skin)
> > A Page Decoration supplies a css style and optionally image references to
>be used by a Page Decorator.
> > Furthermore, a Page Decoration can supply default css styles and
>optionally image references to be used by Menu
> > Decorators and Portlet Decorators.
> >
> > *Menu Decoration* (or skin)
> > A Menu Decoration supplies a css style and optionally image references to
>be used by a Menu Decorator.
> >
> > *Portlet Decoration* (or skin)
> > A Portlet Decoration supplies a css style and optionally image references
>to be used by a Portlet Decorator.
>
>I would like to point out a disadvantage I see with the skinning as
>currently implemented by Jetspeed 1.
>When you supply, say, a background color for a portlet, it actually renders
>that color in the html in a style attribute, like this:
>style="background-color: blue;". The big disadvantage of this is that such
>a style setting cannot be overridden from within the stylesheet. You
>actually have to change the background color in the skin, causing different
>html to be rendered. Another big disadvantage is that you start to mix
>structure and presentation again, even if they are separated in the source
>tree. Yet another problem is that you can only change properties that are
>part of the skin.
>
>I just found from experience that I really didn't like the skinning concept
>as currently implemented in Jetspeed 1, because it goes against my feelings
>of how html should be written, and I actually spent some days rewriting
>templates to get it out.
>
>Here are some things I think are important in a skinning concept:
>
>- All half-important elements in the html page should be 'reachable' from
>the css. This means that every table, cell, paragraph etc. should have a
>class attribute.
>- All elements that are reachable through a 'class', should be reachable
>through an 'id', that should be unique on the page
>- The html should contain as little style elements as possible (no font
>tags, no borders, no bolds etc...)
>- The styling should be contained in the css for as much as possible
>- You should have to modify templates as little as possible for styling
>matters
>
>The styleclass attributes in the skins were an improvement, but I would like
>some well-chosen default values to be set from the start. I would like to be
>able to write css like this:
>
>.portlet
>{
> background-color: white;
> color: darkblue;
>}
>
>.portletTitle
>{
> background-color: darkblue;
> color: white;
>}
>
>Also, I think that, if done right, the 'skin' could end up just being the
>name of a css file, or of a folder containing a bunch of css files.
>Creating a new skin would be creating a new css file (or copying an existing
>one) and writing or modifying the css.
>
>With kind regards,
>
>-Stijn
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation (Offtopic)
Posted by Scott T Weaver <sc...@binary-designs.net>.
Take a look at the portlet decorators in J2. All elements are reachable
by css via class AND id.
On Wed, 2004-06-23 at 20:16, Stijn de Witt wrote:
> ----- Original Message -----
> From: "Ate Douma" <at...@douma.nu>
> To: "Jetspeed Developers List" <je...@jakarta.apache.org>
> Sent: Tuesday, June 22, 2004 7:58 PM
> Subject: Re: [J2] Menu implementation
>
> <SNIP>
>
> > *Page Decoration* (or skin)
> > A Page Decoration supplies a css style and optionally image references to
> be used by a Page Decorator.
> > Furthermore, a Page Decoration can supply default css styles and
> optionally image references to be used by Menu
> > Decorators and Portlet Decorators.
> >
> > *Menu Decoration* (or skin)
> > A Menu Decoration supplies a css style and optionally image references to
> be used by a Menu Decorator.
> >
> > *Portlet Decoration* (or skin)
> > A Portlet Decoration supplies a css style and optionally image references
> to be used by a Portlet Decorator.
>
> I would like to point out a disadvantage I see with the skinning as
> currently implemented by Jetspeed 1.
> When you supply, say, a background color for a portlet, it actually renders
> that color in the html in a style attribute, like this:
> style="background-color: blue;". The big disadvantage of this is that such
> a style setting cannot be overridden from within the stylesheet. You
> actually have to change the background color in the skin, causing different
> html to be rendered. Another big disadvantage is that you start to mix
> structure and presentation again, even if they are separated in the source
> tree. Yet another problem is that you can only change properties that are
> part of the skin.
>
> I just found from experience that I really didn't like the skinning concept
> as currently implemented in Jetspeed 1, because it goes against my feelings
> of how html should be written, and I actually spent some days rewriting
> templates to get it out.
>
> Here are some things I think are important in a skinning concept:
>
> - All half-important elements in the html page should be 'reachable' from
> the css. This means that every table, cell, paragraph etc. should have a
> class attribute.
> - All elements that are reachable through a 'class', should be reachable
> through an 'id', that should be unique on the page
> - The html should contain as little style elements as possible (no font
> tags, no borders, no bolds etc...)
> - The styling should be contained in the css for as much as possible
> - You should have to modify templates as little as possible for styling
> matters
>
> The styleclass attributes in the skins were an improvement, but I would like
> some well-chosen default values to be set from the start. I would like to be
> able to write css like this:
>
> .portlet
> {
> background-color: white;
> color: darkblue;
> }
>
> .portletTitle
> {
> background-color: darkblue;
> color: white;
> }
>
> Also, I think that, if done right, the 'skin' could end up just being the
> name of a css file, or of a folder containing a bunch of css files.
> Creating a new skin would be creating a new css file (or copying an existing
> one) and writing or modifying the css.
>
> With kind regards,
>
> -Stijn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation (Offtopic)
Posted by Stijn de Witt <St...@bergland-it.nl>.
----- Original Message -----
From: "Ate Douma" <at...@douma.nu>
To: "Jetspeed Developers List" <je...@jakarta.apache.org>
Sent: Tuesday, June 22, 2004 7:58 PM
Subject: Re: [J2] Menu implementation
<SNIP>
> *Page Decoration* (or skin)
> A Page Decoration supplies a css style and optionally image references to
be used by a Page Decorator.
> Furthermore, a Page Decoration can supply default css styles and
optionally image references to be used by Menu
> Decorators and Portlet Decorators.
>
> *Menu Decoration* (or skin)
> A Menu Decoration supplies a css style and optionally image references to
be used by a Menu Decorator.
>
> *Portlet Decoration* (or skin)
> A Portlet Decoration supplies a css style and optionally image references
to be used by a Portlet Decorator.
I would like to point out a disadvantage I see with the skinning as
currently implemented by Jetspeed 1.
When you supply, say, a background color for a portlet, it actually renders
that color in the html in a style attribute, like this:
style="background-color: blue;". The big disadvantage of this is that such
a style setting cannot be overridden from within the stylesheet. You
actually have to change the background color in the skin, causing different
html to be rendered. Another big disadvantage is that you start to mix
structure and presentation again, even if they are separated in the source
tree. Yet another problem is that you can only change properties that are
part of the skin.
I just found from experience that I really didn't like the skinning concept
as currently implemented in Jetspeed 1, because it goes against my feelings
of how html should be written, and I actually spent some days rewriting
templates to get it out.
Here are some things I think are important in a skinning concept:
- All half-important elements in the html page should be 'reachable' from
the css. This means that every table, cell, paragraph etc. should have a
class attribute.
- All elements that are reachable through a 'class', should be reachable
through an 'id', that should be unique on the page
- The html should contain as little style elements as possible (no font
tags, no borders, no bolds etc...)
- The styling should be contained in the css for as much as possible
- You should have to modify templates as little as possible for styling
matters
The styleclass attributes in the skins were an improvement, but I would like
some well-chosen default values to be set from the start. I would like to be
able to write css like this:
.portlet
{
background-color: white;
color: darkblue;
}
.portletTitle
{
background-color: darkblue;
color: white;
}
Also, I think that, if done right, the 'skin' could end up just being the
name of a css file, or of a folder containing a bunch of css files.
Creating a new skin would be creating a new css file (or copying an existing
one) and writing or modifying the css.
With kind regards,
-Stijn
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
Okay, registered a user "JetspeedDev" with dev list as the email then
subscribed to the proposal page. However, i don't the source email, so
it will most likely need to be released by list moderator (whomever that
is). We should then probably add the wiki source email to allowed users
for the dev list.
On Wed, 2004-06-23 at 10:45, Scott T Weaver wrote:
> Let me check
>
> On Wed, 2004-06-23 at 10:38, Ate Douma wrote:
> > Scott T Weaver wrote:
> >
> > > Created a jetspeed 2 wiki and I just finished putting your initial
> > > summary out there.
> > >
> > > http://wiki.apache.org/portals/PortalNavigation
> > >
> > That's just great!
> > Can we get wiki update messages be send to the list?
> >
> > >
> > > On Wed, 2004-06-23 at 09:32, Ate Douma wrote:
> > >
> > >>Scott T Weaver wrote:
> > >>
> > >>
> > >>>On Wed, 2004-06-23 at 06:36, Ate Douma wrote:
> > >>>
> > >>>
> > >>>>I'd like to add a few comments to my proposal concerning the elements section of my example (some of which
> > >>>>came up yesterday during a chat I had with David Sean Taylor).
> > >>>>
> > >>>>Here's the elements section again:
> > >>>>
> > >>>> <!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
> > >>>> in the order as defined
> > >>>> -->
> > >>>> <elements>
> > >>>>
> > >>>> <page id="page1" description="Page 1"/>
> > >>>> <page ref="../../subfolder2/page8"/>
> > >>>> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
> > >>>>
> > >>>> <folder id="subfolder1"/>
> > >>>> <folder ref="/subfolder1/subfolder3"/>
> > >>>>
> > >>>> <link url="http://www.apache.org" description="Home Apache" target="_self"/>
> > >>>> <link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
> > >>>>
> > >>>> <!-- hidden elements -->
> > >>>> <page id="page2" hidden="true"/>
> > >>>> <folder id="subfolder2" hidden="true"/>
> > >>>>
> > >>>> </elements>
> > >>>
> > >>>
> > >>>So, we are going to have to have meta-data to describe the folder? I
> > >>>thought links were going to be simple text files with urls in them, not
> > >>>entries in meta-data.
> > >>
> > >>I'm ok with using simple text files for Links (and element references).
> > >>But, there remains the need for some folder meta-data:
> > >>1) Folder description (for menu display)
> > >>2) An optional 'skip' attribute setting
> > >>3) Menu parameters, decorator and decoration configuration.
> > >> Because of the inheritance though this won't be needed in all folders.
> > >>4) Menu element order and hiding elements.
> > >> We can use a default ordering scheme like ordering on the descriptions.
> > >> But, if that's not sufficient, some kind of meta-data will have to be
> > >> specified.
> > >> One option I previously suggested could be defining in within the
> > >> elements (Page definition, Link and element reference files).
> > >> Defining hidden elements can also be done like that.
> > >>
> > >>So, As far as I see, the only really required meta-data needed for all
> > >>the Folders is its description (1). The others are all optional or can be
> > >>solved differently (4).
> > >>What do you think?
> > >
> > > Sounds good to me!
> > >
> > >
> > >>>
> > >>>>In my example all the elements for a menu node are specified, including those not to be displayed
> > >>>>(hidden). The 'hidden' elements really are redundant in this example if all elements are to be specified.
> > >>>>So you can just leave them out.
> > >>>
> > >>>-1. I think reversing it is a better idea so that only special cases
> > >>>(like hidden) need to be specified. The folder meta-data should be
> > >>>entirely optional.
> > >>
> > >>I agree, at least as far as it it possible. See above.
> > >>
> > >>>
> > >>>>But, you still need to specify all which should be displayed. Furthermore, the order in which they are
> > >>>>displayed is derived from it.
> > >>>>
> > >>>>One issue from the previous discussions was that we really should provide a intuitive and easy menu configuration.
> > >>>>Although I think my proposal is very powerfull, it still requires a lot of configuration (but far less then what's needed in J1).
> > >>>
> > >>>
> > >>>definte +1 on ease of use and heavy documentation ;)
> > >>>
> > >>>
> > >>>
> > >>>>Maybe different strategies can be defined for deriving the elements, and their order, so the elements section isn't
> > >>>>always, or not at all, needed.
> > >>>>One way could be allowing 'hidden' and 'order' attributes on Page and Folder configurations.
> > >>>>Still, Link and element references will have to be defined. Maybe it could be done in separate configurations (files) instead
> > >>>>of bundling them in one. Don't know if that would be an improvement though.
> > >>>
> > >>>Again, can't a link be a simple text file with a with a url or maybe it
> > >>>contains an <a href=""> </a> tag in it.
> > >>
> > >>It can. Its still meta-data though. It doesn't matter much I think if its put into one folder-meta-data file or in
> > >>several link/reference files.
> > >>
> > >>
> > >>>
> > >>>>Concerning the 'intuitive' menu definition issue: maybe what is needed is a change of view.
> > >>>>In J1 you won't have a menu unless you define it (completely) on every page which needs one.
> > >>>>Using this proposal, you usually have a standard menu definition (tabmenu on the top, tree menu on the left or something similar).
> > >>>>Only thing needed is a proper menu node configuration instead of a complete definition.
> > >>>>By default, a new Page could be automatically included in a menu unless it is made 'hidden'. It really is more a question of in which folder
> > >>>>the Page should go to get it in the correct menu.
> > >>>
> > >>>+1.
> > >>>
> > >>>
> > >>>
> > >>>>And using Links and Page or Folder references is simply adding them to the correct folder to get them included.
> > >>>>With Links and references the site navigation can be defined 'on top' of the folder structure.
> > >>>
> > >>>+1. Simple and easy to understand, I like it.
> > >>>
> > >>>
> > >>>
> > >>>>Regards,
> > >>>>
> > >>>>Ate
> > >>>>
> > >>>>
> > >>>>---------------------------------------------------------------------
> > >>>>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
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>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
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
Let me check
On Wed, 2004-06-23 at 10:38, Ate Douma wrote:
> Scott T Weaver wrote:
>
> > Created a jetspeed 2 wiki and I just finished putting your initial
> > summary out there.
> >
> > http://wiki.apache.org/portals/PortalNavigation
> >
> That's just great!
> Can we get wiki update messages be send to the list?
>
> >
> > On Wed, 2004-06-23 at 09:32, Ate Douma wrote:
> >
> >>Scott T Weaver wrote:
> >>
> >>
> >>>On Wed, 2004-06-23 at 06:36, Ate Douma wrote:
> >>>
> >>>
> >>>>I'd like to add a few comments to my proposal concerning the elements section of my example (some of which
> >>>>came up yesterday during a chat I had with David Sean Taylor).
> >>>>
> >>>>Here's the elements section again:
> >>>>
> >>>> <!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
> >>>> in the order as defined
> >>>> -->
> >>>> <elements>
> >>>>
> >>>> <page id="page1" description="Page 1"/>
> >>>> <page ref="../../subfolder2/page8"/>
> >>>> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
> >>>>
> >>>> <folder id="subfolder1"/>
> >>>> <folder ref="/subfolder1/subfolder3"/>
> >>>>
> >>>> <link url="http://www.apache.org" description="Home Apache" target="_self"/>
> >>>> <link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
> >>>>
> >>>> <!-- hidden elements -->
> >>>> <page id="page2" hidden="true"/>
> >>>> <folder id="subfolder2" hidden="true"/>
> >>>>
> >>>> </elements>
> >>>
> >>>
> >>>So, we are going to have to have meta-data to describe the folder? I
> >>>thought links were going to be simple text files with urls in them, not
> >>>entries in meta-data.
> >>
> >>I'm ok with using simple text files for Links (and element references).
> >>But, there remains the need for some folder meta-data:
> >>1) Folder description (for menu display)
> >>2) An optional 'skip' attribute setting
> >>3) Menu parameters, decorator and decoration configuration.
> >> Because of the inheritance though this won't be needed in all folders.
> >>4) Menu element order and hiding elements.
> >> We can use a default ordering scheme like ordering on the descriptions.
> >> But, if that's not sufficient, some kind of meta-data will have to be
> >> specified.
> >> One option I previously suggested could be defining in within the
> >> elements (Page definition, Link and element reference files).
> >> Defining hidden elements can also be done like that.
> >>
> >>So, As far as I see, the only really required meta-data needed for all
> >>the Folders is its description (1). The others are all optional or can be
> >>solved differently (4).
> >>What do you think?
> >
> > Sounds good to me!
> >
> >
> >>>
> >>>>In my example all the elements for a menu node are specified, including those not to be displayed
> >>>>(hidden). The 'hidden' elements really are redundant in this example if all elements are to be specified.
> >>>>So you can just leave them out.
> >>>
> >>>-1. I think reversing it is a better idea so that only special cases
> >>>(like hidden) need to be specified. The folder meta-data should be
> >>>entirely optional.
> >>
> >>I agree, at least as far as it it possible. See above.
> >>
> >>>
> >>>>But, you still need to specify all which should be displayed. Furthermore, the order in which they are
> >>>>displayed is derived from it.
> >>>>
> >>>>One issue from the previous discussions was that we really should provide a intuitive and easy menu configuration.
> >>>>Although I think my proposal is very powerfull, it still requires a lot of configuration (but far less then what's needed in J1).
> >>>
> >>>
> >>>definte +1 on ease of use and heavy documentation ;)
> >>>
> >>>
> >>>
> >>>>Maybe different strategies can be defined for deriving the elements, and their order, so the elements section isn't
> >>>>always, or not at all, needed.
> >>>>One way could be allowing 'hidden' and 'order' attributes on Page and Folder configurations.
> >>>>Still, Link and element references will have to be defined. Maybe it could be done in separate configurations (files) instead
> >>>>of bundling them in one. Don't know if that would be an improvement though.
> >>>
> >>>Again, can't a link be a simple text file with a with a url or maybe it
> >>>contains an <a href=""> </a> tag in it.
> >>
> >>It can. Its still meta-data though. It doesn't matter much I think if its put into one folder-meta-data file or in
> >>several link/reference files.
> >>
> >>
> >>>
> >>>>Concerning the 'intuitive' menu definition issue: maybe what is needed is a change of view.
> >>>>In J1 you won't have a menu unless you define it (completely) on every page which needs one.
> >>>>Using this proposal, you usually have a standard menu definition (tabmenu on the top, tree menu on the left or something similar).
> >>>>Only thing needed is a proper menu node configuration instead of a complete definition.
> >>>>By default, a new Page could be automatically included in a menu unless it is made 'hidden'. It really is more a question of in which folder
> >>>>the Page should go to get it in the correct menu.
> >>>
> >>>+1.
> >>>
> >>>
> >>>
> >>>>And using Links and Page or Folder references is simply adding them to the correct folder to get them included.
> >>>>With Links and references the site navigation can be defined 'on top' of the folder structure.
> >>>
> >>>+1. Simple and easy to understand, I like it.
> >>>
> >>>
> >>>
> >>>>Regards,
> >>>>
> >>>>Ate
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>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
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
Scott T Weaver wrote:
> Created a jetspeed 2 wiki and I just finished putting your initial
> summary out there.
>
> http://wiki.apache.org/portals/PortalNavigation
>
That's just great!
Can we get wiki update messages be send to the list?
>
> On Wed, 2004-06-23 at 09:32, Ate Douma wrote:
>
>>Scott T Weaver wrote:
>>
>>
>>>On Wed, 2004-06-23 at 06:36, Ate Douma wrote:
>>>
>>>
>>>>I'd like to add a few comments to my proposal concerning the elements section of my example (some of which
>>>>came up yesterday during a chat I had with David Sean Taylor).
>>>>
>>>>Here's the elements section again:
>>>>
>>>> <!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
>>>> in the order as defined
>>>> -->
>>>> <elements>
>>>>
>>>> <page id="page1" description="Page 1"/>
>>>> <page ref="../../subfolder2/page8"/>
>>>> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>>>>
>>>> <folder id="subfolder1"/>
>>>> <folder ref="/subfolder1/subfolder3"/>
>>>>
>>>> <link url="http://www.apache.org" description="Home Apache" target="_self"/>
>>>> <link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
>>>>
>>>> <!-- hidden elements -->
>>>> <page id="page2" hidden="true"/>
>>>> <folder id="subfolder2" hidden="true"/>
>>>>
>>>> </elements>
>>>
>>>
>>>So, we are going to have to have meta-data to describe the folder? I
>>>thought links were going to be simple text files with urls in them, not
>>>entries in meta-data.
>>
>>I'm ok with using simple text files for Links (and element references).
>>But, there remains the need for some folder meta-data:
>>1) Folder description (for menu display)
>>2) An optional 'skip' attribute setting
>>3) Menu parameters, decorator and decoration configuration.
>> Because of the inheritance though this won't be needed in all folders.
>>4) Menu element order and hiding elements.
>> We can use a default ordering scheme like ordering on the descriptions.
>> But, if that's not sufficient, some kind of meta-data will have to be
>> specified.
>> One option I previously suggested could be defining in within the
>> elements (Page definition, Link and element reference files).
>> Defining hidden elements can also be done like that.
>>
>>So, As far as I see, the only really required meta-data needed for all
>>the Folders is its description (1). The others are all optional or can be
>>solved differently (4).
>>What do you think?
>
> Sounds good to me!
>
>
>>>
>>>>In my example all the elements for a menu node are specified, including those not to be displayed
>>>>(hidden). The 'hidden' elements really are redundant in this example if all elements are to be specified.
>>>>So you can just leave them out.
>>>
>>>-1. I think reversing it is a better idea so that only special cases
>>>(like hidden) need to be specified. The folder meta-data should be
>>>entirely optional.
>>
>>I agree, at least as far as it it possible. See above.
>>
>>>
>>>>But, you still need to specify all which should be displayed. Furthermore, the order in which they are
>>>>displayed is derived from it.
>>>>
>>>>One issue from the previous discussions was that we really should provide a intuitive and easy menu configuration.
>>>>Although I think my proposal is very powerfull, it still requires a lot of configuration (but far less then what's needed in J1).
>>>
>>>
>>>definte +1 on ease of use and heavy documentation ;)
>>>
>>>
>>>
>>>>Maybe different strategies can be defined for deriving the elements, and their order, so the elements section isn't
>>>>always, or not at all, needed.
>>>>One way could be allowing 'hidden' and 'order' attributes on Page and Folder configurations.
>>>>Still, Link and element references will have to be defined. Maybe it could be done in separate configurations (files) instead
>>>>of bundling them in one. Don't know if that would be an improvement though.
>>>
>>>Again, can't a link be a simple text file with a with a url or maybe it
>>>contains an <a href=""> </a> tag in it.
>>
>>It can. Its still meta-data though. It doesn't matter much I think if its put into one folder-meta-data file or in
>>several link/reference files.
>>
>>
>>>
>>>>Concerning the 'intuitive' menu definition issue: maybe what is needed is a change of view.
>>>>In J1 you won't have a menu unless you define it (completely) on every page which needs one.
>>>>Using this proposal, you usually have a standard menu definition (tabmenu on the top, tree menu on the left or something similar).
>>>>Only thing needed is a proper menu node configuration instead of a complete definition.
>>>>By default, a new Page could be automatically included in a menu unless it is made 'hidden'. It really is more a question of in which folder
>>>>the Page should go to get it in the correct menu.
>>>
>>>+1.
>>>
>>>
>>>
>>>>And using Links and Page or Folder references is simply adding them to the correct folder to get them included.
>>>>With Links and references the site navigation can be defined 'on top' of the folder structure.
>>>
>>>+1. Simple and easy to understand, I like it.
>>>
>>>
>>>
>>>>Regards,
>>>>
>>>>Ate
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>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
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
Created a jetspeed 2 wiki and I just finished putting your initial
summary out there.
http://wiki.apache.org/portals/PortalNavigation
On Wed, 2004-06-23 at 09:32, Ate Douma wrote:
> Scott T Weaver wrote:
>
> > On Wed, 2004-06-23 at 06:36, Ate Douma wrote:
> >
> >>I'd like to add a few comments to my proposal concerning the elements section of my example (some of which
> >>came up yesterday during a chat I had with David Sean Taylor).
> >>
> >>Here's the elements section again:
> >>
> >> <!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
> >> in the order as defined
> >> -->
> >> <elements>
> >>
> >> <page id="page1" description="Page 1"/>
> >> <page ref="../../subfolder2/page8"/>
> >> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
> >>
> >> <folder id="subfolder1"/>
> >> <folder ref="/subfolder1/subfolder3"/>
> >>
> >> <link url="http://www.apache.org" description="Home Apache" target="_self"/>
> >> <link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
> >>
> >> <!-- hidden elements -->
> >> <page id="page2" hidden="true"/>
> >> <folder id="subfolder2" hidden="true"/>
> >>
> >> </elements>
> >
> >
> > So, we are going to have to have meta-data to describe the folder? I
> > thought links were going to be simple text files with urls in them, not
> > entries in meta-data.
> I'm ok with using simple text files for Links (and element references).
> But, there remains the need for some folder meta-data:
> 1) Folder description (for menu display)
> 2) An optional 'skip' attribute setting
> 3) Menu parameters, decorator and decoration configuration.
> Because of the inheritance though this won't be needed in all folders.
> 4) Menu element order and hiding elements.
> We can use a default ordering scheme like ordering on the descriptions.
> But, if that's not sufficient, some kind of meta-data will have to be
> specified.
> One option I previously suggested could be defining in within the
> elements (Page definition, Link and element reference files).
> Defining hidden elements can also be done like that.
>
> So, As far as I see, the only really required meta-data needed for all
> the Folders is its description (1). The others are all optional or can be
> solved differently (4).
> What do you think?
Sounds good to me!
>
> >
> >
> >>In my example all the elements for a menu node are specified, including those not to be displayed
> >>(hidden). The 'hidden' elements really are redundant in this example if all elements are to be specified.
> >>So you can just leave them out.
> >
> > -1. I think reversing it is a better idea so that only special cases
> > (like hidden) need to be specified. The folder meta-data should be
> > entirely optional.
> I agree, at least as far as it it possible. See above.
> >
> >
> >>But, you still need to specify all which should be displayed. Furthermore, the order in which they are
> >>displayed is derived from it.
> >>
> >>One issue from the previous discussions was that we really should provide a intuitive and easy menu configuration.
> >>Although I think my proposal is very powerfull, it still requires a lot of configuration (but far less then what's needed in J1).
> >
> >
> > definte +1 on ease of use and heavy documentation ;)
> >
> >
> >>Maybe different strategies can be defined for deriving the elements, and their order, so the elements section isn't
> >>always, or not at all, needed.
> >>One way could be allowing 'hidden' and 'order' attributes on Page and Folder configurations.
> >>Still, Link and element references will have to be defined. Maybe it could be done in separate configurations (files) instead
> >>of bundling them in one. Don't know if that would be an improvement though.
> >
> > Again, can't a link be a simple text file with a with a url or maybe it
> > contains an <a href=""> </a> tag in it.
> It can. Its still meta-data though. It doesn't matter much I think if its put into one folder-meta-data file or in
> several link/reference files.
>
> >
> >
> >>Concerning the 'intuitive' menu definition issue: maybe what is needed is a change of view.
> >>In J1 you won't have a menu unless you define it (completely) on every page which needs one.
> >>Using this proposal, you usually have a standard menu definition (tabmenu on the top, tree menu on the left or something similar).
> >>Only thing needed is a proper menu node configuration instead of a complete definition.
> >>By default, a new Page could be automatically included in a menu unless it is made 'hidden'. It really is more a question of in which folder
> >>the Page should go to get it in the correct menu.
> >
> > +1.
> >
> >
> >>And using Links and Page or Folder references is simply adding them to the correct folder to get them included.
> >>With Links and references the site navigation can be defined 'on top' of the folder structure.
> >
> > +1. Simple and easy to understand, I like it.
> >
> >
> >>Regards,
> >>
> >>Ate
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
Scott T Weaver wrote:
> On Wed, 2004-06-23 at 06:36, Ate Douma wrote:
>
>>I'd like to add a few comments to my proposal concerning the elements section of my example (some of which
>>came up yesterday during a chat I had with David Sean Taylor).
>>
>>Here's the elements section again:
>>
>> <!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
>> in the order as defined
>> -->
>> <elements>
>>
>> <page id="page1" description="Page 1"/>
>> <page ref="../../subfolder2/page8"/>
>> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>>
>> <folder id="subfolder1"/>
>> <folder ref="/subfolder1/subfolder3"/>
>>
>> <link url="http://www.apache.org" description="Home Apache" target="_self"/>
>> <link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
>>
>> <!-- hidden elements -->
>> <page id="page2" hidden="true"/>
>> <folder id="subfolder2" hidden="true"/>
>>
>> </elements>
>
>
> So, we are going to have to have meta-data to describe the folder? I
> thought links were going to be simple text files with urls in them, not
> entries in meta-data.
I'm ok with using simple text files for Links (and element references).
But, there remains the need for some folder meta-data:
1) Folder description (for menu display)
2) An optional 'skip' attribute setting
3) Menu parameters, decorator and decoration configuration.
Because of the inheritance though this won't be needed in all folders.
4) Menu element order and hiding elements.
We can use a default ordering scheme like ordering on the descriptions.
But, if that's not sufficient, some kind of meta-data will have to be
specified.
One option I previously suggested could be defining in within the
elements (Page definition, Link and element reference files).
Defining hidden elements can also be done like that.
So, As far as I see, the only really required meta-data needed for all
the Folders is its description (1). The others are all optional or can be
solved differently (4).
What do you think?
>
>
>>In my example all the elements for a menu node are specified, including those not to be displayed
>>(hidden). The 'hidden' elements really are redundant in this example if all elements are to be specified.
>>So you can just leave them out.
>
> -1. I think reversing it is a better idea so that only special cases
> (like hidden) need to be specified. The folder meta-data should be
> entirely optional.
I agree, at least as far as it it possible. See above.
>
>
>>But, you still need to specify all which should be displayed. Furthermore, the order in which they are
>>displayed is derived from it.
>>
>>One issue from the previous discussions was that we really should provide a intuitive and easy menu configuration.
>>Although I think my proposal is very powerfull, it still requires a lot of configuration (but far less then what's needed in J1).
>
>
> definte +1 on ease of use and heavy documentation ;)
>
>
>>Maybe different strategies can be defined for deriving the elements, and their order, so the elements section isn't
>>always, or not at all, needed.
>>One way could be allowing 'hidden' and 'order' attributes on Page and Folder configurations.
>>Still, Link and element references will have to be defined. Maybe it could be done in separate configurations (files) instead
>>of bundling them in one. Don't know if that would be an improvement though.
>
> Again, can't a link be a simple text file with a with a url or maybe it
> contains an <a href=""> </a> tag in it.
It can. Its still meta-data though. It doesn't matter much I think if its put into one folder-meta-data file or in
several link/reference files.
>
>
>>Concerning the 'intuitive' menu definition issue: maybe what is needed is a change of view.
>>In J1 you won't have a menu unless you define it (completely) on every page which needs one.
>>Using this proposal, you usually have a standard menu definition (tabmenu on the top, tree menu on the left or something similar).
>>Only thing needed is a proper menu node configuration instead of a complete definition.
>>By default, a new Page could be automatically included in a menu unless it is made 'hidden'. It really is more a question of in which folder
>>the Page should go to get it in the correct menu.
>
> +1.
>
>
>>And using Links and Page or Folder references is simply adding them to the correct folder to get them included.
>>With Links and references the site navigation can be defined 'on top' of the folder structure.
>
> +1. Simple and easy to understand, I like it.
>
>
>>Regards,
>>
>>Ate
>>
>>
>>---------------------------------------------------------------------
>>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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
On Wed, 2004-06-23 at 06:36, Ate Douma wrote:
> I'd like to add a few comments to my proposal concerning the elements section of my example (some of which
> came up yesterday during a chat I had with David Sean Taylor).
>
> Here's the elements section again:
>
> <!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
> in the order as defined
> -->
> <elements>
>
> <page id="page1" description="Page 1"/>
> <page ref="../../subfolder2/page8"/>
> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>
> <folder id="subfolder1"/>
> <folder ref="/subfolder1/subfolder3"/>
>
> <link url="http://www.apache.org" description="Home Apache" target="_self"/>
> <link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
>
> <!-- hidden elements -->
> <page id="page2" hidden="true"/>
> <folder id="subfolder2" hidden="true"/>
>
> </elements>
So, we are going to have to have meta-data to describe the folder? I
thought links were going to be simple text files with urls in them, not
entries in meta-data.
>
> In my example all the elements for a menu node are specified, including those not to be displayed
> (hidden). The 'hidden' elements really are redundant in this example if all elements are to be specified.
> So you can just leave them out.
-1. I think reversing it is a better idea so that only special cases
(like hidden) need to be specified. The folder meta-data should be
entirely optional.
>
> But, you still need to specify all which should be displayed. Furthermore, the order in which they are
> displayed is derived from it.
>
> One issue from the previous discussions was that we really should provide a intuitive and easy menu configuration.
> Although I think my proposal is very powerfull, it still requires a lot of configuration (but far less then what's needed in J1).
definte +1 on ease of use and heavy documentation ;)
>
> Maybe different strategies can be defined for deriving the elements, and their order, so the elements section isn't
> always, or not at all, needed.
> One way could be allowing 'hidden' and 'order' attributes on Page and Folder configurations.
> Still, Link and element references will have to be defined. Maybe it could be done in separate configurations (files) instead
> of bundling them in one. Don't know if that would be an improvement though.
Again, can't a link be a simple text file with a with a url or maybe it
contains an <a href=""> </a> tag in it.
>
> Concerning the 'intuitive' menu definition issue: maybe what is needed is a change of view.
> In J1 you won't have a menu unless you define it (completely) on every page which needs one.
> Using this proposal, you usually have a standard menu definition (tabmenu on the top, tree menu on the left or something similar).
> Only thing needed is a proper menu node configuration instead of a complete definition.
> By default, a new Page could be automatically included in a menu unless it is made 'hidden'. It really is more a question of in which folder
> the Page should go to get it in the correct menu.
+1.
> And using Links and Page or Folder references is simply adding them to the correct folder to get them included.
> With Links and references the site navigation can be defined 'on top' of the folder structure.
+1. Simple and easy to understand, I like it.
>
> Regards,
>
> Ate
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
I'd like to add a few comments to my proposal concerning the elements section of my example (some of which
came up yesterday during a chat I had with David Sean Taylor).
Here's the elements section again:
<!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
in the order as defined
-->
<elements>
<page id="page1" description="Page 1"/>
<page ref="../../subfolder2/page8"/>
<page ref="/subfolder1/subfolder2/page9" description="Page 9" />
<folder id="subfolder1"/>
<folder ref="/subfolder1/subfolder3"/>
<link url="http://www.apache.org" description="Home Apache" target="_self"/>
<link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
<!-- hidden elements -->
<page id="page2" hidden="true"/>
<folder id="subfolder2" hidden="true"/>
</elements>
In my example all the elements for a menu node are specified, including those not to be displayed
(hidden). The 'hidden' elements really are redundant in this example if all elements are to be specified.
So you can just leave them out.
But, you still need to specify all which should be displayed. Furthermore, the order in which they are
displayed is derived from it.
One issue from the previous discussions was that we really should provide a intuitive and easy menu configuration.
Although I think my proposal is very powerfull, it still requires a lot of configuration (but far less then what's needed in J1).
Maybe different strategies can be defined for deriving the elements, and their order, so the elements section isn't
always, or not at all, needed.
One way could be allowing 'hidden' and 'order' attributes on Page and Folder configurations.
Still, Link and element references will have to be defined. Maybe it could be done in separate configurations (files) instead
of bundling them in one. Don't know if that would be an improvement though.
Concerning the 'intuitive' menu definition issue: maybe what is needed is a change of view.
In J1 you won't have a menu unless you define it (completely) on every page which needs one.
Using this proposal, you usually have a standard menu definition (tabmenu on the top, tree menu on the left or something similar).
Only thing needed is a proper menu node configuration instead of a complete definition.
By default, a new Page could be automatically included in a menu unless it is made 'hidden'. It really is more a question of in which folder
the Page should go to get it in the correct menu.
And using Links and Page or Folder references is simply adding them to the correct folder to get them included.
With Links and references the site navigation can be defined 'on top' of the folder structure.
Regards,
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jun 22, 2004, at 10:58 AM, Ate Douma wrote:
> After the long discussion we already had in this thread, I've tried to
> capture all the comments to get to a Menu (and Folder) implementation
> design which you find below.
>
> I also added a few enhancements (decorator/decoration inheritance and
> overrides) myself.
> All in all it has become a quite long proposal in which I tried to pin
> down most issues I could think of.
> I don't expect to have covered all correctly yet though, and maybe I
> just got it plain wrong :-)
> But, this is how I now see it.
>
> Hopefully this clear things up a bit though and I hope it provides
> enough food for a continued discussion.
> Lets get this thing nailed down soon!
>
Thanks for your consideration and thoroughness in including everyones
requirements in this document.
Im wondering if this feature *we* are proposing should be called
"SiteMap" instead of "Menus" since it covers more than just menus.
What do you think?
Regarding the metadata on folders, that was partially necessary to meet
my requirements:
- references (symlinks) to other pages
- links (outside the site)
Perhaps the first implementation should not support these features.
In J1 we had menus defined on the page.
The menus were very useful in that you could display only the selected
fragment (or portlet), hiding all others.
How does this menu proposal address what I will call 'Page Navigation',
since the J1 menus really navigated around the fragments of a page?
If we plan to abandon this popular feature, I think we need to clearly
state: "We are abandoning fragment-based menus and navigation for these
reasons ..."
And state the reasons so that people porting their J1 applications will
know why and redesign their applications appropriately.
> Regards, Ate
> -----------------------------------------------------------------------
> -------------------------------------------------
> *Folder*
> A Folder is an aggregate of Pages, Folders and Links. It is not
> viewable or renderable but only used to group its
> elements in an ordered manner. Its elements all have a parent
> reference to their containing Folder.
> The Folder structure and hierarchy is the basis for Page navigation,
> layout, decoration and Menu rendering.
> There is only one root Folder without parent. That simplifies the
> definition of default Decorators and Decorations.
>
> *Folder elements*
> A Folder element (Page, Folder, Link) is defined within it or may be a
> reference to a element defined in another Folder
> (like Unix symbolic links), which may be a reference in itself.
>
Great!
Im glad you remembered our discussion from Friday when I suggested
using (sym) links (references) to solve the external page requirement.
BTW - 'references' is exactly what I called them in J1, not sure if you
were aware of the term and making the transition easier for my closed
J1 perspective ;-)...
Also consider another element type, Scott mentioned that he would like
to see 'documents' of none-portlet content including in the
navigational space
For example, an HTML or WML page
I want to point out that none of the folder metadata below is required
Meaning you can have a folder with a default menu without defining any
of the definitions below
What that menu contains is not entirely clear thus far
It could contain, by a configurable default, all the level 1 elements
(folders, pages)
> <folder id="subfolder16" description="Sub folder 16" skip="false">
>
> <!-- The value attribute in the decorator definitions below
> reference a parent variable to which
> the decorator must be assigned.
> As an example the below page definition can be programmed as:
>
> folder.setPageDecorator("default", pageDecorator);
> -->
> <decorator id="jetspeed" type="page" value="default"
> decoration="jetspeed-blue">
>
> <!-- specify as default topmenu menu decorator a pulldownmenu
> with an marine menu decoration -->
> <decorator id="pulldownmenu" type="menu" value="topmenu"
> decoration="marine"/>
>
> <!-- override the default decoration on the leftmenu menu
> decorator for this folder -->
> <decorator type="menu" value="leftmenu"
> decoration="yellow"/>
>
> <!-- default disable the rightmenu decorator for this folder -->
> <decorator type="menu" value="rightmenu"
> disabled="true"/>
>
> <!-- specify as default portlet decorator the jetspeed portlet
> decorator with jetspeed-blue decoration-->
> <decorator id="jetspeed" type="portlet" value="default"
> decoration="jetspeed-blue"/>
> </decorator>
>
> <!-- menu parameters -->
> <menu id="tabmenu" level="1" depth="2"/>
> <menu id="treemenu" level="3" depth="0"/>
>
> <!-- Folder elements displayed in the menu (in the current example
> in tabmenu if level < 3 or in treemenu otherwise)
> in the order as defined
> -->
> <elements>
>
> <page id="page1" description="Page 1"/>
> <page ref="../../subfolder2/page8"/>
> <page ref="/subfolder1/subfolder2/page9" description="Page 9" />
>
> <folder id="subfolder1"/>
> <folder ref="/subfolder1/subfolder3"/>
>
> <link url="http://www.apache.org" description="Home Apache"
> target="_self"/>
> <link url="http://portals.apache.org" description="Home Apache
> Portals" target="outside"/>
>
> <!-- hidden elements -->
> <page id="page2" hidden="true"/>
> <folder id="subfolder2" hidden="true"/>
>
> </elements>
>
> </folder>
> -----------------------------------------------------------------------
> --------------------------------------------------
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
Ate Douma wrote:
>
>
> David Sean Taylor wrote:
>
>>
>> On Jun 22, 2004, at 10:58 AM, Ate Douma wrote:
>>
>>>
>>> *Page Decorator*
>>> A Page Decorator renders the border (including header and footer) and
>>> possibly one or more menus around the Page content
>>> as well as the layout of the Fragments output from a Page (e.g.
>>> column or row wise, single/maximized).
>>> Menu rendering (if supported) is delegated by the Page Decorator to a
>>> Menu Decorator. If more than one menu is supported
>>> a Menu Decorator must be defined for each. Also, explicitly
>>> suppressing the rendering of one or more menus must be
>>> possible.
>>>
>>>
>>> *Page Decoration* (or skin)
>>> A Page Decoration supplies a css style and optionally image
>>> references to be used by a Page Decorator.
>>> Furthermore, a Page Decoration can supply default css styles and
>>> optionally image references to be used by Menu
>>> Decorators and Portlet Decorators.
>>>
>> The terms "Decorator" and "Decoration" are very close and may lead to
>> confusion
>
> They are already used and described in design doc "j2 Layout and
> decorator handling.pdf"
I need to correct myself. Those terms are described in the above mentioned document but not with the same meaning.
I agree: the terms as I used them are confusing.
Maybe skin or style is more appropriate instead of Decoration?
I also thought of 'theme' but that seems to cover more. Maybe decorators and skins together could be called that.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
>
> On Jun 22, 2004, at 10:58 AM, Ate Douma wrote:
>
>>
>> *Page Decorator*
>> A Page Decorator renders the border (including header and footer) and
>> possibly one or more menus around the Page content
>> as well as the layout of the Fragments output from a Page (e.g. column
>> or row wise, single/maximized).
>> Menu rendering (if supported) is delegated by the Page Decorator to a
>> Menu Decorator. If more than one menu is supported
>> a Menu Decorator must be defined for each. Also, explicitly
>> suppressing the rendering of one or more menus must be
>> possible.
>>
>>
>> *Page Decoration* (or skin)
>> A Page Decoration supplies a css style and optionally image references
>> to be used by a Page Decorator.
>> Furthermore, a Page Decoration can supply default css styles and
>> optionally image references to be used by Menu
>> Decorators and Portlet Decorators.
>>
> The terms "Decorator" and "Decoration" are very close and may lead to
> confusion
They are already used and described in design doc "j2 Layout and decorator handling.pdf"
which you co-authored :-)
But if you have better alternatives please let us know.
>
>
> ---------------------------------------------------------------------
> 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
RE: [J2] Menu implementation
Posted by Tim Reilly <ti...@consultant.com>.
I'd also like to throw in the fact that my initial thought (_prior_ to
reading "j2 Layout and decorator handling.pdf") was that it referred to the
pattern - GoF, Gamma et al.
> From: David Sean Taylor
> Sent: Wednesday, June 23, 2004 11:05 AM
> To: Jetspeed Developers List
> Subject: Re: [J2] Menu implementation
>
>
>
> On Jun 22, 2004, at 10:58 AM, Ate Douma wrote:
> >
> > *Page Decorator*
> > A Page Decorator renders the border (including header and footer) and
> > possibly one or more menus around the Page content
> > as well as the layout of the Fragments output from a Page (e.g. column
> > or row wise, single/maximized).
> > Menu rendering (if supported) is delegated by the Page Decorator to a
> > Menu Decorator. If more than one menu is supported
> > a Menu Decorator must be defined for each. Also, explicitly
> > suppressing the rendering of one or more menus must be
> > possible.
> >
> >
> > *Page Decoration* (or skin)
> > A Page Decoration supplies a css style and optionally image references
> > to be used by a Page Decorator.
> > Furthermore, a Page Decoration can supply default css styles and
> > optionally image references to be used by Menu
> > Decorators and Portlet Decorators.
> >
> The terms "Decorator" and "Decoration" are very close and may lead to
> confusion
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jun 22, 2004, at 10:58 AM, Ate Douma wrote:
>
> *Page Decorator*
> A Page Decorator renders the border (including header and footer) and
> possibly one or more menus around the Page content
> as well as the layout of the Fragments output from a Page (e.g. column
> or row wise, single/maximized).
> Menu rendering (if supported) is delegated by the Page Decorator to a
> Menu Decorator. If more than one menu is supported
> a Menu Decorator must be defined for each. Also, explicitly
> suppressing the rendering of one or more menus must be
> possible.
>
>
> *Page Decoration* (or skin)
> A Page Decoration supplies a css style and optionally image references
> to be used by a Page Decorator.
> Furthermore, a Page Decoration can supply default css styles and
> optionally image references to be used by Menu
> Decorators and Portlet Decorators.
>
The terms "Decorator" and "Decoration" are very close and may lead to
confusion
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
After the long discussion we already had in this thread, I've tried to capture all the comments to get to a Menu (and
Folder) implementation design which you find below.
I also added a few enhancements (decorator/decoration inheritance and overrides) myself.
All in all it has become a quite long proposal in which I tried to pin down most issues I could think of.
I don't expect to have covered all correctly yet though, and maybe I just got it plain wrong :-)
But, this is how I now see it.
Hopefully this clear things up a bit though and I hope it provides enough food for a continued discussion.
Lets get this thing nailed down soon!
Regards, Ate
------------------------------------------------------------------------------------------------------------------------
*Folder*
A Folder is an aggregate of Pages, Folders and Links. It is not viewable or renderable but only used to group its
elements in an ordered manner. Its elements all have a parent reference to their containing Folder.
The Folder structure and hierarchy is the basis for Page navigation, layout, decoration and Menu rendering.
There is only one root Folder without parent. That simplifies the definition of default Decorators and Decorations.
*Folder elements*
A Folder element (Page, Folder, Link) is defined within it or may be a reference to a element defined in another Folder
(like Unix symbolic links), which may be a reference in itself.
Deleting an element will result in references defined to become invalid.
Elements which are a reference to another Element defined in another Folder will have as parent the Folder containing
them. For referenced Folder elements though, its elements will still have as parent the referenced Folder itself, not
the Folder reference. This means that navigating to an element within a referenced Folder will result in a change of the
parent hierarchy.
*Page*
A Page is an aggregate of Fragments and Page configuration. A Page is always used for rendering the end result to the
user. The Page used is determined by the Profiler based on the client capabilities, navigation parameters and/or request
parameters.
When a Page is rendered all of its Fragments are rendered for as far as allowed based on possible security
constraints. It is not possible to reference a single Fragment on a Page for rendering (or possibly using a different
pipeline).
*Fragment*
A Fragment is a markup definition for content to be rendered by a portlet. Two types are supported:
layout and portlet. A layout Fragment definition contains nested Fragments to be layout by it 'layout' portlet. A
portlet Fragment cannot contain nested Fragments.
Instead of a concrete Fragment definition it is possible to reference another Fragment defined within the Page or from
another Page. External Fragment references are 'included' during rendering and become part of the Page including them
and only the decoration and layout configurations from this Page apply.
*Link*
A Link is a reference to an external url to be displayed in a menu.
*Page Decorator*
A Page Decorator renders the border (including header and footer) and possibly one or more menus around the Page content
as well as the layout of the Fragments output from a Page (e.g. column or row wise, single/maximized).
Menu rendering (if supported) is delegated by the Page Decorator to a Menu Decorator. If more than one menu is supported
a Menu Decorator must be defined for each. Also, explicitly suppressing the rendering of one or more menus must be
possible.
*Menu Decorator*
A Menu Decorator is used by a Page Decorator to do the actual rendering of a menu. Depending on the Page Decorator
capabilities, zero, one or more menus may be rendered on a Page. A Page Decorator could support a top tab menu and
a left tree menu for instance.
A menu displays Folder elements as navigation links from the current Page. Normally, the current Page, or its first
parent within the menu will be marked.
Two *root* Folder relative parameters control which Folder elements are to be displayed in the menu: depth and level.
The level parameter specifies from which level down in the Folder hierarchy the menu rendering should start.
Minimum value: 1.
The depth parameter specifies how many levels the menu rendering may continue. Minimum value: 0, indicating all
remaining levels (useful for tree menus).
Optionally, each Folder element can be configured to be excluded from menu rendering.
Additionally, a Folder can be configured to be skipped for current level determination. Those Folders are traversed for
menu rendering but not included by it (nor its non-Folder elements). For instance the Folders used by the
Profiler to find a matching Page (e.g. client capability Folders as wml or html, language Folders as en, fr, nl) could
be skipped.
*Portlet Decorator*
A Portlet Decorator is used for rendering the markup around a portlet Fragment output.
*Decorator lookup*
Each of the above decorators can be defined within a Page definition, be inherited from the containing Folder or even
from higher up in the Folder hierarchy. A Portlet Decorator may also be defined on a portlet Fragment within a Page.
The nearest definition will be used.
As fallback the *root* Folder shall have a default configuration for each of these (including default menu parameters).
*Page Decoration* (or skin)
A Page Decoration supplies a css style and optionally image references to be used by a Page Decorator.
Furthermore, a Page Decoration can supply default css styles and optionally image references to be used by Menu
Decorators and Portlet Decorators.
*Menu Decoration* (or skin)
A Menu Decoration supplies a css style and optionally image references to be used by a Menu Decorator.
*Portlet Decoration* (or skin)
A Portlet Decoration supplies a css style and optionally image references to be used by a Portlet Decorator.
*Example Folder configuration*
<folder id="subfolder16" description="Sub folder 16" skip="false">
<!-- The value attribute in the decorator definitions below reference a parent variable to which
the decorator must be assigned.
As an example the below page definition can be programmed as:
folder.setPageDecorator("default", pageDecorator);
-->
<decorator id="jetspeed" type="page" value="default" decoration="jetspeed-blue">
<!-- specify as default topmenu menu decorator a pulldownmenu with an marine menu decoration -->
<decorator id="pulldownmenu" type="menu" value="topmenu" decoration="marine"/>
<!-- override the default decoration on the leftmenu menu decorator for this folder -->
<decorator type="menu" value="leftmenu" decoration="yellow"/>
<!-- default disable the rightmenu decorator for this folder -->
<decorator type="menu" value="rightmenu" disabled="true"/>
<!-- specify as default portlet decorator the jetspeed portlet decorator with jetspeed-blue decoration-->
<decorator id="jetspeed" type="portlet" value="default" decoration="jetspeed-blue"/>
</decorator>
<!-- menu parameters -->
<menu id="tabmenu" level="1" depth="2"/>
<menu id="treemenu" level="3" depth="0"/>
<!-- Folder elements displayed in the menu (in the current example in tabmenu if level < 3 or in treemenu otherwise)
in the order as defined
-->
<elements>
<page id="page1" description="Page 1"/>
<page ref="../../subfolder2/page8"/>
<page ref="/subfolder1/subfolder2/page9" description="Page 9" />
<folder id="subfolder1"/>
<folder ref="/subfolder1/subfolder3"/>
<link url="http://www.apache.org" description="Home Apache" target="_self"/>
<link url="http://portals.apache.org" description="Home Apache Portals" target="outside"/>
<!-- hidden elements -->
<page id="page2" hidden="true"/>
<folder id="subfolder2" hidden="true"/>
</elements>
</folder>
-------------------------------------------------------------------------------------------------------------------------
Ate Douma wrote:
> I've been trying to get a clear picture of what the options and
> positions are about menu creation for J2.
>
> I'm quite lost after reviewing several sources:
> - 1) current J1 impl
> - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
> - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
> ([J2} Proposal for Layout, pages & Decorator handling in J2)
> - 4) http://nagoya.apache.org/jira/browse/JS2-69
> (Finalizing Portal Navigation using the Profiler)
>
> A few design issues needs to be addressed I think to be able to decide
> on the impl. of menus.
>
> - Nested pages
> Should these be allowed?
> Part of that question is what a Page is.
> The pdf (see 2) says its to be considered a Fragment.
> If this is meant as a "fragment" which can be included, alright. But, I
> don't see how it also can
> be a "Fragment" (note the case) or why it should be made one.
>
> Fragments already can contain other Fragments though. This is more or
> less in analogy to nested
> portlets in J1 I belief.
>
> Maybe one reason why one would want to nest pages is to be able to
> define different decoration on a nested page.
> It has been suggested by Scott (see 4) to allow for the most flexible
> way possible this should be possible
> (even up/down overrides if needed).
>
> To me, this seems to lead to very complex psml though. I would certainly
> like to see a more
> simple model implemented first before going that road.
>
> Probably the same result could be created without page nesting using
> fragment references. These could
> reference other pages (pulling in their decorator definitions with them)
> or fragments within other pages.
> As far as I can tell, then there would be no need to define pages within
> pages.
>
> - Folder or menu elements
> The Folder concept containing other folders and/or pages could be used
> to generate menus as proposed by Scott (see 4).
> Something I'm missing right now is a clear understanding how/where
> folders are defined. I found the om impl but no usage
> yet so its something I can't relate to enough yet to really decide if
> I'm going to like it or not.
>
> One important issue I would have with it though is that it wouldn't
> allow me to render page fragments/portlets in a menu, not external links.
> Likewise, I don't see how a TabbedPane could be rendered for the current
> page using the folder
> concept.
>
> The other proposal from David Taylor was defining new psml menu and
> menu-item elements which could reference pages, (external) fragments and
> external links (see 3).
> I understand Scott didn't like adding additional data structures into
> the mix (see 4), but I for one would prefer this
> above the folder/page -> menu concept. AFAIK its way more flexible and
> probably much easier to understand for a user.
> And, it isn't that different from the J1 implementation. Recreating the
> current J1 features for J2 will be relatively easier to do I think.
>
> Note: I know the folder concept is not *just* about menus. I'm not
> opposed to folders in anyway. I just think its
> to restricted for menu rendering.
>
> I'd like some comments and if already possible a vote which way we
> should go about menu rendering.
> I know I'll something soon ;-)
>
> Regards,
>
> Ate
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
On Fri, 2004-06-18 at 17:57, Ate Douma wrote:
> David Sean Taylor wrote:
>
> >
> > On Jun 18, 2004, at 2:31 PM, Ate Douma wrote:
> >
> >>>>
> >>>> 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).
> >
> >
> > A subfolder is just a page (PSML) right?
> Wow. I didn't get that one yet.
> I have the impression Scott wants to derive folders directly from
> filesystem folders.
Yes. That is exactly what I had in mind.
> His comment on 6/16/2004:
> >> Do I understand it now correctly that folders (for a file based Page Manager)
> >> are simply derived from filesystem folders?
> > That is how I see it. Or possibly using a VFS file system.
> Furthermore, how would that psml look like? If a folder is a page, a folder
> contains pages, and pages are all defined in their own psml you need external
> references to define containment...
>
> > So the ACL is on the page in its respective PSML file
> >
> > For ordering, you need some metadata on the top level page
> >
> >> 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.
> >
> >
> > I think I misunderstand this. Wouldn't the menu for a page only have the
> > menu-items from the immediate subpages (by default) below it?
> > The user could then add or remove(disable) as needed
> Normally not.
> Consider a menu of depth 2 (Scott's example).
> If I'm on a page from depth 1 and navigate to a page from depth2 wouldn't I want
> to see the exact same menu (only indicating a different selection).
> And if I navigate to a page from depth 3 I probably again want to see the same
> menu. The parent folder (depth 2) menu item should then be selected.
> A tree type menu (on the left) of unlimited depth starting from depth 3 would then
> indicate the current page selection.
> This is only one use case but a valid and a very common one I think.
Yes, Ate this is a perfect use case. I would like to here others takes
on use cases also just so we don't miss something.
>
> >
> >> 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.
> >>
> > Im sorry but I don't understand what you are saying here
> If you take the example I gave above, the menu (depth) configuration really should
> be defined on the 'top' folder and be inherited/enforced below. If we need to define
> this on or through each and every page definition it becomes troublesome to update it.
>
> >
> >>>> 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...
> >>
> > You lost me again. Do you mean immediately above?
> > The whole point of PSML is that has a model that can be customized.
> > When you customize, you manipulate PSML
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
On Fri, 2004-06-18 at 18:23, David Sean Taylor wrote:
> On Jun 18, 2004, at 2:57 PM, Ate Douma wrote:
>
> >
> >
> > David Sean Taylor wrote:
> >
> >> On Jun 18, 2004, at 2:31 PM, Ate Douma wrote:
> >>>>>
> >>>>> 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).
> >> A subfolder is just a page (PSML) right?
> > Wow. I didn't get that one yet.
> > I have the impression Scott wants to derive folders directly from
> > filesystem folders.
>
> I think Im following more now.
> I'll try to make some clearer definitions:
>
> Folders are not pages.
> Folders are containers
> Folders have menus
> Folders do not have fragments
Bingo!
>
>
> > His comment on 6/16/2004:
> > >> Do I understand it now correctly that folders (for a file based
> > Page Manager)
> > >> are simply derived from filesystem folders?
> > > That is how I see it. Or possibly using a VFS file system.
> > Furthermore, how would that psml look like? If a folder is a page, a
> > folder
> > contains pages, and pages are all defined in their own psml you need
> > external
> > references to define containment...
>
> Well I think you are trying to say that a folder is not a page.
> I wasn't trying to suggest that it was; I was more trying to express my
> understanding of what I thought you were proposing
> As for external references, I still have the requirement for that. See
> my requirement example
>
> >
> >> So the ACL is on the page in its respective PSML file
> >> For ordering, you need some metadata on the top level page
> >>> 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.
> >> I think I misunderstand this. Wouldn't the menu for a page only have
> >> the menu-items from the immediate subpages (by default) below it?
> >> The user could then add or remove(disable) as needed
> > Normally not.
> > Consider a menu of depth 2 (Scott's example).
> > If I'm on a page from depth 1 and navigate to a page from depth2
> > wouldn't I want
> > to see the exact same menu (only indicating a different selection).
> > And if I navigate to a page from depth 3 I probably again want to see
> > the same
> > menu. The parent folder (depth 2) menu item should then be selected.
> > A tree type menu (on the left) of unlimited depth starting from depth
> > 3 would then
> > indicate the current page selection.
> > This is only one use case but a valid and a very common one I think.
> >
>
> Menus can be defined at 1..n levels in a folder
> The use case makes it clear now
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jun 18, 2004, at 2:57 PM, Ate Douma wrote:
>
>
> David Sean Taylor wrote:
>
>> On Jun 18, 2004, at 2:31 PM, Ate Douma wrote:
>>>>>
>>>>> 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).
>> A subfolder is just a page (PSML) right?
> Wow. I didn't get that one yet.
> I have the impression Scott wants to derive folders directly from
> filesystem folders.
I think Im following more now.
I'll try to make some clearer definitions:
Folders are not pages.
Folders are containers
Folders have menus
Folders do not have fragments
> His comment on 6/16/2004:
> >> Do I understand it now correctly that folders (for a file based
> Page Manager)
> >> are simply derived from filesystem folders?
> > That is how I see it. Or possibly using a VFS file system.
> Furthermore, how would that psml look like? If a folder is a page, a
> folder
> contains pages, and pages are all defined in their own psml you need
> external
> references to define containment...
Well I think you are trying to say that a folder is not a page.
I wasn't trying to suggest that it was; I was more trying to express my
understanding of what I thought you were proposing
As for external references, I still have the requirement for that. See
my requirement example
>
>> So the ACL is on the page in its respective PSML file
>> For ordering, you need some metadata on the top level page
>>> 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.
>> I think I misunderstand this. Wouldn't the menu for a page only have
>> the menu-items from the immediate subpages (by default) below it?
>> The user could then add or remove(disable) as needed
> Normally not.
> Consider a menu of depth 2 (Scott's example).
> If I'm on a page from depth 1 and navigate to a page from depth2
> wouldn't I want
> to see the exact same menu (only indicating a different selection).
> And if I navigate to a page from depth 3 I probably again want to see
> the same
> menu. The parent folder (depth 2) menu item should then be selected.
> A tree type menu (on the left) of unlimited depth starting from depth
> 3 would then
> indicate the current page selection.
> This is only one use case but a valid and a very common one I think.
>
Menus can be defined at 1..n levels in a folder
The use case makes it clear now
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
>
> On Jun 18, 2004, at 2:31 PM, Ate Douma wrote:
>
>>>>
>>>> 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).
>
>
> A subfolder is just a page (PSML) right?
Wow. I didn't get that one yet.
I have the impression Scott wants to derive folders directly from
filesystem folders.
His comment on 6/16/2004:
>> Do I understand it now correctly that folders (for a file based Page Manager)
>> are simply derived from filesystem folders?
> That is how I see it. Or possibly using a VFS file system.
Furthermore, how would that psml look like? If a folder is a page, a folder
contains pages, and pages are all defined in their own psml you need external
references to define containment...
> So the ACL is on the page in its respective PSML file
>
> For ordering, you need some metadata on the top level page
>
>> 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.
>
>
> I think I misunderstand this. Wouldn't the menu for a page only have the
> menu-items from the immediate subpages (by default) below it?
> The user could then add or remove(disable) as needed
Normally not.
Consider a menu of depth 2 (Scott's example).
If I'm on a page from depth 1 and navigate to a page from depth2 wouldn't I want
to see the exact same menu (only indicating a different selection).
And if I navigate to a page from depth 3 I probably again want to see the same
menu. The parent folder (depth 2) menu item should then be selected.
A tree type menu (on the left) of unlimited depth starting from depth 3 would then
indicate the current page selection.
This is only one use case but a valid and a very common one I think.
>
>> 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.
>>
> Im sorry but I don't understand what you are saying here
If you take the example I gave above, the menu (depth) configuration really should
be defined on the 'top' folder and be inherited/enforced below. If we need to define
this on or through each and every page definition it becomes troublesome to update it.
>
>>>> 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...
>>
> You lost me again. Do you mean immediately above?
> The whole point of PSML is that has a model that can be customized.
> When you customize, you manipulate PSML
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
On Fri, 2004-06-18 at 17:41, David Sean Taylor wrote:
> On Jun 18, 2004, at 2:31 PM, Ate Douma wrote:
> >>>
> >>> 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).
>
> A subfolder is just a page (PSML) right?
No. It is a physical folder. We would probably need some meta-data to
describe it though.
So the ACL is on the page in its respective PSML file
>
> For ordering, you need some metadata on the top level page
Well, probably in the folder meta-data. However, when users customize
the order of a folder, we should store this as user preferences
>
> > 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.
>
> I think I misunderstand this. Wouldn't the menu for a page only have
> the menu-items from the immediate subpages (by default) below it?
> The user could then add or remove(disable) as needed
Navigation has nothing to do with the page itself. Navigation is based
on the resources (folders and pages) the the user currently has access
to.
>
> > 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.
> >
> Im sorry but I don't understand what you are saying here
Again, a page has no need to know anything about navigation as it
doesn't and shouldn't have any control over it.
>
> >>> 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...
> >
> You lost me again. Do you mean immediately above?
> The whole point of PSML is that has a model that can be customized.
> When you customize, you manipulate PSML
Yes for customizing an individual page, not the navigational hierarchy.
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jun 18, 2004, at 2:31 PM, Ate Douma wrote:
>>>
>>> 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).
A subfolder is just a page (PSML) right?
So the ACL is on the page in its respective PSML file
For ordering, you need some metadata on the top level page
> 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.
I think I misunderstand this. Wouldn't the menu for a page only have
the menu-items from the immediate subpages (by default) below it?
The user could then add or remove(disable) as needed
> 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.
>
Im sorry but I don't understand what you are saying here
>>> 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...
>
You lost me again. Do you mean immediately above?
The whole point of PSML is that has a model that can be customized.
When you customize, you manipulate PSML
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
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
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
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
Re: [J2] Menu implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
Scott, thanks for the answers. I still do have a few questions though...
See below.
Scott T Weaver wrote:
> 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?
What I meant was if .menu or folder navigation would be configurable per root
folder OR only globally for Jetspeed as a whole (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.
I'd like the idea but would want it optional, maybe even per user/group/role.
>
>
>
>
>> > 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.
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.
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?
>
>>
>>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: 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
>>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
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: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
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?
> 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 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?
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: 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
Re: [J2] Menu implementation
Posted by Serge Huber <sh...@jahia.com>.
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
Maybe you could forward your lost response(s) to the list also?
Scott T Weaver wrote:
> For some reason, Roger's reply-to is his email instead of the list.
>
> On Thu, 2004-06-17 at 15:28, Ate Douma wrote:
>
>>I think there are some responses *lost* on the list.
>>In the response from Roger I see several included comments from Scott which haven't been
>>received on the list (also not in the eyebrowse archives).
>>But Roger seems to have received them.
>>Scott, have you mailed roger directly or did we lose something on the list?
>>
>>Roger Ruttimann wrote:
>>
>>>Scott T Weaver wrote:
>>>
>>>
>>>>On Thu, 2004-06-17 at 11:25, Roger Ruttimann wrote:
>>>>
>>>>
>>>>
>>>>>David Sean Taylor wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>David Sean Taylor wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>To me, this seems to lead to very complex psml though. I would
>>>>>>>>>>certainly like to see a more
>>>>>>>>>>simple model implemented first before going that road.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Im -1 on nested pages, and +1 on nested fragments (references),
>>>>>>>>>which
>>>>>>>>>does not need to be implemented in the first solution
>>>>>>>>>
>>>>>>>>
>>>>>>>>+1
>>>>>>>>
>>>>>>>
>>>>>>>Also -1 on nested pages.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Nested fragments, but not as references, are already used by the
>>>>>>>>layout portlets!
>>>>>>>>
>>>>>>>
>>>>>>>I would also like to add support for non-portlet fragments, like raw
>>>>>>>html, etc.
>>>>>>>
>>>>>>
>>>>>>That would just be a different fragment type, such as "markup"
>>>>>>These markup fragments will need a deployable model, like decorators
>>>>>>It first it would seem we lose all the benefits of a portal if we
>>>>>>put in HTML-specific markup,
>>>>>>On the other hand, if your PSML pages were markup specific, like
>>>>>>what J1 currently supports, it makes more sense
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>Probably the same result could be created without page nesting
>>>>>>>>>>using
>>>>>>>>>>fragment references. These could
>>>>>>>>>>reference other pages (pulling in their decorator definitions with
>>>>>>>>>>them) or fragments within other pages.
>>>>>>>>>>As far as I can tell, then there would be no need to define pages
>>>>>>>>>>within pages.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Fragments do not need to be associated with a page, at least not
>>>>>>>>>in a
>>>>>>>>>database implementation
>>>>>>>>>See the database model for PSML in the J2 CVS
>>>>>>>>>
>>>>>>>>
>>>>>>>>I think if we are going to support non-page based fragments (for
>>>>>>>>references)
>>>>>>>>we should also provide a file based implementation. Dunno if you
>>>>>>>>should still
>>>>>>>>call it psml then though.
>>>>>>>>
>>>>>>>
>>>>>>>Believe it or not, I am beginning to think the non-RDBMS XML
>>>>>>>file-based
>>>>>>>page system is a better approach than the RDBMS one. It fits better
>>>>>>>into CMS model than an RDBMS page manager does. We could also use VFS
>>>>>>>to abstract the file system were the pages reside. VFS also
>>>>>>>supports a
>>>>>>>WebDAV based file system out the box.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Well it does make some sense and certainly simplifies things
>>>>>>RDMBS PSML can just be an implementation for those who need it. It
>>>>>>doesn't need to be implemented first.
>>>>>>
>>>>>
>>>>>+1 Since it is more likely that JCMS will manage the pages.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>For scalable systems, from my experience a more robust Page Manager
>>>>>>will be required than simply putting the pages on the file system
>>>>>>with no sharing across nodes
>>>>>>
>>>>>>With WebDAV interfaces, we could push all of that logic (locking,
>>>>>>versioning) back to the CMS Server and not have to deal with it
>>>>>>That is one of the goals of JCMS
>>>>>>Perhaps we should look into a VFS-backed JCMS for the WebDAV support
>>>>>>
>>>>>>I will try to work on getting JCMS into incubator so that people can
>>>>>>look at it
>>>>>>The current base system has a small footprint, and I'd still prefer
>>>>>>it to go into J2 as a component
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>I believe the page within a page concept can be easily supported
>>>>>>>>>via the
>>>>>>>>>profiler's portal URI space, a CMS-like tree
>>>>>>>>>
>>>>>>>>
>>>>>>>>Using folder semantics you mean? Then I'm +1.
>>>>>>>>
>>>>>>>
>>>>>>>I also think the folder metaphor is the best approach.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>- Folder or menu elements
>>>>>>>>>>The Folder concept containing other folders and/or pages could
>>>>>>>>>>be used
>>>>>>>>>>to generate menus as proposed by Scott (see 4).
>>>>>>>>>>Something I'm missing right now is a clear understanding how/where
>>>>>>>>>>folders are defined. I found the om impl but no usage
>>>>>>>>>>yet so its something I can't relate to enough yet to really
>>>>>>>>>>decide if
>>>>>>>>>>I'm going to like it or not.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Couldn't the Page Manager support the concept of folders in its
>>>>>>>>>model?
>>>>>>>>>Im also wondering if the Page Manager should support the JCMS API
>>>>>>>>>
>>>>>>>>
>>>>>>>>One thing at a time please ;-)
>>>>>>>>Do I understand it now correctly that folders (for a file based
>>>>>>>>Page Manager)
>>>>>>>>are simply derived from filesystem folders?
>>>>>>>>
>>>>>>>
>>>>>>>That is how I see it. Or possibly using a VFS file system.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Im still not convinced that VFS should be coupled to Jetspeed
>>>>>>Prefer coupling at the JCMS level
>>>>>>I will get some interfaces out on the web today for review
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>So no definition needed in the psml.
>>>>>>>>Of course, a DB Page Manager would still require explicit folder
>>>>>>>>configuration.
>>>>>>>>
>>>>>>>
>>>>>>>That is why I am leaning more towards a page-based system.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>If we have folders and pages can't JCMS support be added then "on
>>>>>>>>top" later?
>>>>>>>>
>>>>>>>
>>>>>>>+1. JCMS may over complicate things in in the beginning.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>I don't think so, review the interfaces first before passing
>>>>>>judgment ;)
>>>>>>
>>>>
>>>>Well, JCMS is just one more thing end users will have to get their head
>>>>around before they can start using Jetspeed 2. I really don't know how
>>>>I feel about that. I would be persuaded if some would step up and write
>>>>some good user docs on how to the two work together.
>>>>
>>>>
>>>
>>>The two components (page/menu & JCMS) could be developed independently.
>>>Once the features are stable the page/menus could be integrated into
>>>JCMS. Reducing the dependencies for the initial implementation helps to
>>>speed up the J2 development.
>>>
>>>
>>>>
>>>>
>>>>
>>>>>If we decide to use folders/files structures for the page/menu
>>>>>implementation the JCMS integration could be done in parallel while
>>>>>the PSML-2 & rendering is implemented. The definition and the
>>>>>inital implementation of the inital pages/menu implementation should
>>>>>not be dependent on JCMS.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>>>One important issue I would have with it though is that it wouldn't
>>>>>>>>>>allow me to render page fragments/portlets in a menu, not
>>>>>>>>>>external links.
>>>>>>>>>>Likewise, I don't see how a TabbedPane could be rendered for the
>>>>>>>>>>current page using the folder
>>>>>>>>>>concept.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>I believe the tabbed pane could automatically pick up the folder's
>>>>>>>>>children nodes as its menu options
>>>>>>>>>This is a valid use case, but not the only use case
>>>>>>>>>
>>>>>>>>
>>>>>>>>I meant in this case a TabbedPane displaying fragments defined
>>>>>>>>*within* a page.
>>>>>>>>
>>>>>>>
>>>>>>>I don't I like idea of navigating "within" a page. A page should be
>>>>>>>your final stop, all fragments being rendered at once.
>>>>>>>
>>>>>>
>>>>>>The ability to navigate within a page was a popular feature in J1
>>>>>>(the impl caused me endless headaches)
>>>>>>For example, nested menus where only the selected portlet from the
>>>>>>fragment set is displayed and all
>>>>>>other portlets are hidden
>>>>>>
>>>>>>I think we could leverage the portlet API to achieve the same thing,
>>>>>>through maximize mode
>>>>>>Although nesting maximized portlets is not really supported
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>You won't have a folder then.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>What about external links, links to other pages...
>>>>>>>>>Or perhaps the folder is how someone defines a menu
>>>>>>>>>
>>>>>>>
>>>>>>>What about having a special link file that you drop into a folder?
>>>>>>>Just
>>>>>>>a plain text file with url in it. You could even go as far as
>>>>>>>dropping
>>>>>>>velocity template into a folder to support more complicated menu items
>>>>>>>and such.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>For a external link, I think a menu definition is simpler and easier
>>>>>>to understand
>>>>>>This does sound intriguing though, each menu option could have its
>>>>>>own decorations and style
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>The other proposal from David Taylor was defining new psml menu and
>>>>>>>>>>menu-item elements which could reference pages, (external)
>>>>>>>>>>fragments
>>>>>>>>>>and external links (see 3).
>>>>>>>>>>I understand Scott didn't like adding additional data structures
>>>>>>>>>>into
>>>>>>>>>>the mix (see 4), but I for one would prefer this
>>>>>>>>>>above the folder/page -> menu concept. AFAIK its way more
>>>>>>>>>>flexible and
>>>>>>>>>>probably much easier to understand for a user.
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>And, it isn't that different from the J1 implementation. Recreating
>>>>>>>>>>the current J1 features for J2 will be relatively easier to do I
>>>>>>>>>>think.
>>>>>>>>>>
>>>>>>>>>>Note: I know the folder concept is not *just* about menus. I'm not
>>>>>>>>>>opposed to folders in anyway. I just think its
>>>>>>>>>>to restricted for menu rendering.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Can we support both, or is that too confusing to the end user?
>>>>>>>>>See 4 for the menu xml syntax:
>>>>>>>>>
>>>>>>>>><menu type='folder' url='/myfolder'/>
>>>>>>>>>
>>>>>>>>>which would generate a menu based on a folder
>>>>>>>>>
>>>>>>>>
>>>>>>>>+1. I'm all for folder support on this. But not to be restricted
>>>>>>>>by it.
>>>>>>>>
>>>>>>>
>>>>>>>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).
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>This sounds reasonable for folders.
>>>>>>When the user navigates to a folder, they get the default menu for
>>>>>>that folder, all nodes within that folder.
>>>>>>
>>>>>>However, how would you put a menu on a page?
>>>>>>This could be solved by not differentiating between folders and
>>>>>>pages, and treat them all alike.
>>>>>>Whereas many systems treat pages as leaf nodes, PSML pages could be
>>>>>>considered as non-leaf nodes like folders.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Next we introduce the idea of a navigation renderer that would consume
>>>>>>>and render either .menu files OR folder/page structures. 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.
>>>>>>>
>>>>>>>The navigation renderer gives us a very fine grained control over
>>>>>>>how we
>>>>>>>render our navigation and separates the model (.menu or folders) from
>>>>>>>the view.
>>>>>>>
>>>>>>>Custom ordering of navigation could be done by storing item order in
>>>>>>>user preferences.
>>>>>>>
>>>>>
>>>>>Why introducing .menu files if it could be defined in a folder? I
>>>>>prefer to keep the syntax as simple as possible.
>>>>>
>>>>
>>>>+1
>>>>
>>>>
>>>>
>>>>>>Where is the renderer defined, in the fragment or menu?
>>>>>>This seems very cool but a bit complicated
>>>>>>
>>>>
>>>>Neither, since rendering is a look and feel/view concern you would code
>>>>it directly into the layout template, i.e. directly into
>>>>decorations/layout/jetspeed/jetspeed_top.vm
>>>>
>>>>
>>>>
>>>>
>>>>>>The part that Im trying to solve is how can the user clearly define
>>>>>>menus
>>>>>>If we are introducing renderers and implementation details into the
>>>>>>mix, I think it confuses the simplicity of the model
>>>>>>
>>>>>
>>>>>I agree that the mix of rendering and implementation is a bit too
>>>>>complicated. Different levels of rendering migth confuse more than it
>>>>>helps to create menus.
>>>>>
>>>>
>>>>
>>>>How about adding 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.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>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
>>>
>>>
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
For some reason, Roger's reply-to is his email instead of the list.
On Thu, 2004-06-17 at 15:28, Ate Douma wrote:
> I think there are some responses *lost* on the list.
> In the response from Roger I see several included comments from Scott which haven't been
> received on the list (also not in the eyebrowse archives).
> But Roger seems to have received them.
> Scott, have you mailed roger directly or did we lose something on the list?
>
> Roger Ruttimann wrote:
> > Scott T Weaver wrote:
> >
> >> On Thu, 2004-06-17 at 11:25, Roger Ruttimann wrote:
> >>
> >>
> >>> David Sean Taylor wrote:
> >>>
> >>>
> >>>
> >>>> On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> David Sean Taylor wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> To me, this seems to lead to very complex psml though. I would
> >>>>>>>> certainly like to see a more
> >>>>>>>> simple model implemented first before going that road.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> Im -1 on nested pages, and +1 on nested fragments (references),
> >>>>>>> which
> >>>>>>> does not need to be implemented in the first solution
> >>>>>>>
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>
> >>>>> Also -1 on nested pages.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Nested fragments, but not as references, are already used by the
> >>>>>> layout portlets!
> >>>>>>
> >>>>>
> >>>>> I would also like to add support for non-portlet fragments, like raw
> >>>>> html, etc.
> >>>>>
> >>>>
> >>>> That would just be a different fragment type, such as "markup"
> >>>> These markup fragments will need a deployable model, like decorators
> >>>> It first it would seem we lose all the benefits of a portal if we
> >>>> put in HTML-specific markup,
> >>>> On the other hand, if your PSML pages were markup specific, like
> >>>> what J1 currently supports, it makes more sense
> >>>>
> >>>>
> >>>>
> >>>>>>>> Probably the same result could be created without page nesting
> >>>>>>>> using
> >>>>>>>> fragment references. These could
> >>>>>>>> reference other pages (pulling in their decorator definitions with
> >>>>>>>> them) or fragments within other pages.
> >>>>>>>> As far as I can tell, then there would be no need to define pages
> >>>>>>>> within pages.
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Fragments do not need to be associated with a page, at least not
> >>>>>>> in a
> >>>>>>> database implementation
> >>>>>>> See the database model for PSML in the J2 CVS
> >>>>>>>
> >>>>>>
> >>>>>> I think if we are going to support non-page based fragments (for
> >>>>>> references)
> >>>>>> we should also provide a file based implementation. Dunno if you
> >>>>>> should still
> >>>>>> call it psml then though.
> >>>>>>
> >>>>>
> >>>>> Believe it or not, I am beginning to think the non-RDBMS XML
> >>>>> file-based
> >>>>> page system is a better approach than the RDBMS one. It fits better
> >>>>> into CMS model than an RDBMS page manager does. We could also use VFS
> >>>>> to abstract the file system were the pages reside. VFS also
> >>>>> supports a
> >>>>> WebDAV based file system out the box.
> >>>>>
> >>>>>
> >>>>
> >>>> Well it does make some sense and certainly simplifies things
> >>>> RDMBS PSML can just be an implementation for those who need it. It
> >>>> doesn't need to be implemented first.
> >>>>
> >>>
> >>> +1 Since it is more likely that JCMS will manage the pages.
> >>>
> >>>
> >>>
> >>>> For scalable systems, from my experience a more robust Page Manager
> >>>> will be required than simply putting the pages on the file system
> >>>> with no sharing across nodes
> >>>>
> >>>> With WebDAV interfaces, we could push all of that logic (locking,
> >>>> versioning) back to the CMS Server and not have to deal with it
> >>>> That is one of the goals of JCMS
> >>>> Perhaps we should look into a VFS-backed JCMS for the WebDAV support
> >>>>
> >>>> I will try to work on getting JCMS into incubator so that people can
> >>>> look at it
> >>>> The current base system has a small footprint, and I'd still prefer
> >>>> it to go into J2 as a component
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>> I believe the page within a page concept can be easily supported
> >>>>>>> via the
> >>>>>>> profiler's portal URI space, a CMS-like tree
> >>>>>>>
> >>>>>>
> >>>>>> Using folder semantics you mean? Then I'm +1.
> >>>>>>
> >>>>>
> >>>>> I also think the folder metaphor is the best approach.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>> - Folder or menu elements
> >>>>>>>> The Folder concept containing other folders and/or pages could
> >>>>>>>> be used
> >>>>>>>> to generate menus as proposed by Scott (see 4).
> >>>>>>>> Something I'm missing right now is a clear understanding how/where
> >>>>>>>> folders are defined. I found the om impl but no usage
> >>>>>>>> yet so its something I can't relate to enough yet to really
> >>>>>>>> decide if
> >>>>>>>> I'm going to like it or not.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Couldn't the Page Manager support the concept of folders in its
> >>>>>>> model?
> >>>>>>> Im also wondering if the Page Manager should support the JCMS API
> >>>>>>>
> >>>>>>
> >>>>>> One thing at a time please ;-)
> >>>>>> Do I understand it now correctly that folders (for a file based
> >>>>>> Page Manager)
> >>>>>> are simply derived from filesystem folders?
> >>>>>>
> >>>>>
> >>>>> That is how I see it. Or possibly using a VFS file system.
> >>>>>
> >>>>>
> >>>>
> >>>> Im still not convinced that VFS should be coupled to Jetspeed
> >>>> Prefer coupling at the JCMS level
> >>>> I will get some interfaces out on the web today for review
> >>>>
> >>>>
> >>>>
> >>>>>> So no definition needed in the psml.
> >>>>>> Of course, a DB Page Manager would still require explicit folder
> >>>>>> configuration.
> >>>>>>
> >>>>>
> >>>>> That is why I am leaning more towards a page-based system.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> If we have folders and pages can't JCMS support be added then "on
> >>>>>> top" later?
> >>>>>>
> >>>>>
> >>>>> +1. JCMS may over complicate things in in the beginning.
> >>>>>
> >>>>>
> >>>>
> >>>> I don't think so, review the interfaces first before passing
> >>>> judgment ;)
> >>>>
> >>
> >> Well, JCMS is just one more thing end users will have to get their head
> >> around before they can start using Jetspeed 2. I really don't know how
> >> I feel about that. I would be persuaded if some would step up and write
> >> some good user docs on how to the two work together.
> >>
> >>
> >
> > The two components (page/menu & JCMS) could be developed independently.
> > Once the features are stable the page/menus could be integrated into
> > JCMS. Reducing the dependencies for the initial implementation helps to
> > speed up the J2 development.
> >
> >>
> >>
> >>> If we decide to use folders/files structures for the page/menu
> >>> implementation the JCMS integration could be done in parallel while
> >>> the PSML-2 & rendering is implemented. The definition and the
> >>> inital implementation of the inital pages/menu implementation should
> >>> not be dependent on JCMS.
> >>>
> >>>
> >>>
> >>>>>>>> One important issue I would have with it though is that it wouldn't
> >>>>>>>> allow me to render page fragments/portlets in a menu, not
> >>>>>>>> external links.
> >>>>>>>> Likewise, I don't see how a TabbedPane could be rendered for the
> >>>>>>>> current page using the folder
> >>>>>>>> concept.
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> I believe the tabbed pane could automatically pick up the folder's
> >>>>>>> children nodes as its menu options
> >>>>>>> This is a valid use case, but not the only use case
> >>>>>>>
> >>>>>>
> >>>>>> I meant in this case a TabbedPane displaying fragments defined
> >>>>>> *within* a page.
> >>>>>>
> >>>>>
> >>>>> I don't I like idea of navigating "within" a page. A page should be
> >>>>> your final stop, all fragments being rendered at once.
> >>>>>
> >>>>
> >>>> The ability to navigate within a page was a popular feature in J1
> >>>> (the impl caused me endless headaches)
> >>>> For example, nested menus where only the selected portlet from the
> >>>> fragment set is displayed and all
> >>>> other portlets are hidden
> >>>>
> >>>> I think we could leverage the portlet API to achieve the same thing,
> >>>> through maximize mode
> >>>> Although nesting maximized portlets is not really supported
> >>>>
> >>>>
> >>>>
> >>>>>> You won't have a folder then.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> What about external links, links to other pages...
> >>>>>>> Or perhaps the folder is how someone defines a menu
> >>>>>>>
> >>>>>
> >>>>> What about having a special link file that you drop into a folder?
> >>>>> Just
> >>>>> a plain text file with url in it. You could even go as far as
> >>>>> dropping
> >>>>> velocity template into a folder to support more complicated menu items
> >>>>> and such.
> >>>>>
> >>>>>
> >>>>
> >>>> For a external link, I think a menu definition is simpler and easier
> >>>> to understand
> >>>> This does sound intriguing though, each menu option could have its
> >>>> own decorations and style
> >>>>
> >>>>
> >>>>
> >>>>>>>> The other proposal from David Taylor was defining new psml menu and
> >>>>>>>> menu-item elements which could reference pages, (external)
> >>>>>>>> fragments
> >>>>>>>> and external links (see 3).
> >>>>>>>> I understand Scott didn't like adding additional data structures
> >>>>>>>> into
> >>>>>>>> the mix (see 4), but I for one would prefer this
> >>>>>>>> above the folder/page -> menu concept. AFAIK its way more
> >>>>>>>> flexible and
> >>>>>>>> probably much easier to understand for a user.
> >>>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>> And, it isn't that different from the J1 implementation. Recreating
> >>>>>>>> the current J1 features for J2 will be relatively easier to do I
> >>>>>>>> think.
> >>>>>>>>
> >>>>>>>> Note: I know the folder concept is not *just* about menus. I'm not
> >>>>>>>> opposed to folders in anyway. I just think its
> >>>>>>>> to restricted for menu rendering.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> Can we support both, or is that too confusing to the end user?
> >>>>>>> See 4 for the menu xml syntax:
> >>>>>>>
> >>>>>>> <menu type='folder' url='/myfolder'/>
> >>>>>>>
> >>>>>>> which would generate a menu based on a folder
> >>>>>>>
> >>>>>>
> >>>>>> +1. I'm all for folder support on this. But not to be restricted
> >>>>>> by it.
> >>>>>>
> >>>>>
> >>>>> 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).
> >>>>>
> >>>>>
> >>>>
> >>>> This sounds reasonable for folders.
> >>>> When the user navigates to a folder, they get the default menu for
> >>>> that folder, all nodes within that folder.
> >>>>
> >>>> However, how would you put a menu on a page?
> >>>> This could be solved by not differentiating between folders and
> >>>> pages, and treat them all alike.
> >>>> Whereas many systems treat pages as leaf nodes, PSML pages could be
> >>>> considered as non-leaf nodes like folders.
> >>>>
> >>>>
> >>>>
> >>>>> Next we introduce the idea of a navigation renderer that would consume
> >>>>> and render either .menu files OR folder/page structures. 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.
> >>>>>
> >>>>> The navigation renderer gives us a very fine grained control over
> >>>>> how we
> >>>>> render our navigation and separates the model (.menu or folders) from
> >>>>> the view.
> >>>>>
> >>>>> Custom ordering of navigation could be done by storing item order in
> >>>>> user preferences.
> >>>>>
> >>>
> >>> Why introducing .menu files if it could be defined in a folder? I
> >>> prefer to keep the syntax as simple as possible.
> >>>
> >>
> >> +1
> >>
> >>
> >>>> Where is the renderer defined, in the fragment or menu?
> >>>> This seems very cool but a bit complicated
> >>>>
> >>
> >> Neither, since rendering is a look and feel/view concern you would code
> >> it directly into the layout template, i.e. directly into
> >> decorations/layout/jetspeed/jetspeed_top.vm
> >>
> >>
> >>
> >>>> The part that Im trying to solve is how can the user clearly define
> >>>> menus
> >>>> If we are introducing renderers and implementation details into the
> >>>> mix, I think it confuses the simplicity of the model
> >>>>
> >>>
> >>> I agree that the mix of rendering and implementation is a bit too
> >>> complicated. Different levels of rendering migth confuse more than it
> >>> helps to create menus.
> >>>
> >>
> >>
> >> How about adding 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.
> >>
> >>
> >>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
I think there are some responses *lost* on the list.
In the response from Roger I see several included comments from Scott which haven't been
received on the list (also not in the eyebrowse archives).
But Roger seems to have received them.
Scott, have you mailed roger directly or did we lose something on the list?
Roger Ruttimann wrote:
> Scott T Weaver wrote:
>
>> On Thu, 2004-06-17 at 11:25, Roger Ruttimann wrote:
>>
>>
>>> David Sean Taylor wrote:
>>>
>>>
>>>
>>>> On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote:
>>>>
>>>>
>>>>
>>>>> On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
>>>>>
>>>>>
>>>>>
>>>>>> David Sean Taylor wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> To me, this seems to lead to very complex psml though. I would
>>>>>>>> certainly like to see a more
>>>>>>>> simple model implemented first before going that road.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Im -1 on nested pages, and +1 on nested fragments (references),
>>>>>>> which
>>>>>>> does not need to be implemented in the first solution
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>
>>>>> Also -1 on nested pages.
>>>>>
>>>>>
>>>>>
>>>>>> Nested fragments, but not as references, are already used by the
>>>>>> layout portlets!
>>>>>>
>>>>>
>>>>> I would also like to add support for non-portlet fragments, like raw
>>>>> html, etc.
>>>>>
>>>>
>>>> That would just be a different fragment type, such as "markup"
>>>> These markup fragments will need a deployable model, like decorators
>>>> It first it would seem we lose all the benefits of a portal if we
>>>> put in HTML-specific markup,
>>>> On the other hand, if your PSML pages were markup specific, like
>>>> what J1 currently supports, it makes more sense
>>>>
>>>>
>>>>
>>>>>>>> Probably the same result could be created without page nesting
>>>>>>>> using
>>>>>>>> fragment references. These could
>>>>>>>> reference other pages (pulling in their decorator definitions with
>>>>>>>> them) or fragments within other pages.
>>>>>>>> As far as I can tell, then there would be no need to define pages
>>>>>>>> within pages.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fragments do not need to be associated with a page, at least not
>>>>>>> in a
>>>>>>> database implementation
>>>>>>> See the database model for PSML in the J2 CVS
>>>>>>>
>>>>>>
>>>>>> I think if we are going to support non-page based fragments (for
>>>>>> references)
>>>>>> we should also provide a file based implementation. Dunno if you
>>>>>> should still
>>>>>> call it psml then though.
>>>>>>
>>>>>
>>>>> Believe it or not, I am beginning to think the non-RDBMS XML
>>>>> file-based
>>>>> page system is a better approach than the RDBMS one. It fits better
>>>>> into CMS model than an RDBMS page manager does. We could also use VFS
>>>>> to abstract the file system were the pages reside. VFS also
>>>>> supports a
>>>>> WebDAV based file system out the box.
>>>>>
>>>>>
>>>>
>>>> Well it does make some sense and certainly simplifies things
>>>> RDMBS PSML can just be an implementation for those who need it. It
>>>> doesn't need to be implemented first.
>>>>
>>>
>>> +1 Since it is more likely that JCMS will manage the pages.
>>>
>>>
>>>
>>>> For scalable systems, from my experience a more robust Page Manager
>>>> will be required than simply putting the pages on the file system
>>>> with no sharing across nodes
>>>>
>>>> With WebDAV interfaces, we could push all of that logic (locking,
>>>> versioning) back to the CMS Server and not have to deal with it
>>>> That is one of the goals of JCMS
>>>> Perhaps we should look into a VFS-backed JCMS for the WebDAV support
>>>>
>>>> I will try to work on getting JCMS into incubator so that people can
>>>> look at it
>>>> The current base system has a small footprint, and I'd still prefer
>>>> it to go into J2 as a component
>>>>
>>>>
>>>>
>>>>
>>>>>>> I believe the page within a page concept can be easily supported
>>>>>>> via the
>>>>>>> profiler's portal URI space, a CMS-like tree
>>>>>>>
>>>>>>
>>>>>> Using folder semantics you mean? Then I'm +1.
>>>>>>
>>>>>
>>>>> I also think the folder metaphor is the best approach.
>>>>>
>>>>>
>>>>>
>>>>>>>> - Folder or menu elements
>>>>>>>> The Folder concept containing other folders and/or pages could
>>>>>>>> be used
>>>>>>>> to generate menus as proposed by Scott (see 4).
>>>>>>>> Something I'm missing right now is a clear understanding how/where
>>>>>>>> folders are defined. I found the om impl but no usage
>>>>>>>> yet so its something I can't relate to enough yet to really
>>>>>>>> decide if
>>>>>>>> I'm going to like it or not.
>>>>>>>>
>>>>>>>
>>>>>>> Couldn't the Page Manager support the concept of folders in its
>>>>>>> model?
>>>>>>> Im also wondering if the Page Manager should support the JCMS API
>>>>>>>
>>>>>>
>>>>>> One thing at a time please ;-)
>>>>>> Do I understand it now correctly that folders (for a file based
>>>>>> Page Manager)
>>>>>> are simply derived from filesystem folders?
>>>>>>
>>>>>
>>>>> That is how I see it. Or possibly using a VFS file system.
>>>>>
>>>>>
>>>>
>>>> Im still not convinced that VFS should be coupled to Jetspeed
>>>> Prefer coupling at the JCMS level
>>>> I will get some interfaces out on the web today for review
>>>>
>>>>
>>>>
>>>>>> So no definition needed in the psml.
>>>>>> Of course, a DB Page Manager would still require explicit folder
>>>>>> configuration.
>>>>>>
>>>>>
>>>>> That is why I am leaning more towards a page-based system.
>>>>>
>>>>>
>>>>>
>>>>>> If we have folders and pages can't JCMS support be added then "on
>>>>>> top" later?
>>>>>>
>>>>>
>>>>> +1. JCMS may over complicate things in in the beginning.
>>>>>
>>>>>
>>>>
>>>> I don't think so, review the interfaces first before passing
>>>> judgment ;)
>>>>
>>
>> Well, JCMS is just one more thing end users will have to get their head
>> around before they can start using Jetspeed 2. I really don't know how
>> I feel about that. I would be persuaded if some would step up and write
>> some good user docs on how to the two work together.
>>
>>
>
> The two components (page/menu & JCMS) could be developed independently.
> Once the features are stable the page/menus could be integrated into
> JCMS. Reducing the dependencies for the initial implementation helps to
> speed up the J2 development.
>
>>
>>
>>> If we decide to use folders/files structures for the page/menu
>>> implementation the JCMS integration could be done in parallel while
>>> the PSML-2 & rendering is implemented. The definition and the
>>> inital implementation of the inital pages/menu implementation should
>>> not be dependent on JCMS.
>>>
>>>
>>>
>>>>>>>> One important issue I would have with it though is that it wouldn't
>>>>>>>> allow me to render page fragments/portlets in a menu, not
>>>>>>>> external links.
>>>>>>>> Likewise, I don't see how a TabbedPane could be rendered for the
>>>>>>>> current page using the folder
>>>>>>>> concept.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I believe the tabbed pane could automatically pick up the folder's
>>>>>>> children nodes as its menu options
>>>>>>> This is a valid use case, but not the only use case
>>>>>>>
>>>>>>
>>>>>> I meant in this case a TabbedPane displaying fragments defined
>>>>>> *within* a page.
>>>>>>
>>>>>
>>>>> I don't I like idea of navigating "within" a page. A page should be
>>>>> your final stop, all fragments being rendered at once.
>>>>>
>>>>
>>>> The ability to navigate within a page was a popular feature in J1
>>>> (the impl caused me endless headaches)
>>>> For example, nested menus where only the selected portlet from the
>>>> fragment set is displayed and all
>>>> other portlets are hidden
>>>>
>>>> I think we could leverage the portlet API to achieve the same thing,
>>>> through maximize mode
>>>> Although nesting maximized portlets is not really supported
>>>>
>>>>
>>>>
>>>>>> You won't have a folder then.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> What about external links, links to other pages...
>>>>>>> Or perhaps the folder is how someone defines a menu
>>>>>>>
>>>>>
>>>>> What about having a special link file that you drop into a folder?
>>>>> Just
>>>>> a plain text file with url in it. You could even go as far as
>>>>> dropping
>>>>> velocity template into a folder to support more complicated menu items
>>>>> and such.
>>>>>
>>>>>
>>>>
>>>> For a external link, I think a menu definition is simpler and easier
>>>> to understand
>>>> This does sound intriguing though, each menu option could have its
>>>> own decorations and style
>>>>
>>>>
>>>>
>>>>>>>> The other proposal from David Taylor was defining new psml menu and
>>>>>>>> menu-item elements which could reference pages, (external)
>>>>>>>> fragments
>>>>>>>> and external links (see 3).
>>>>>>>> I understand Scott didn't like adding additional data structures
>>>>>>>> into
>>>>>>>> the mix (see 4), but I for one would prefer this
>>>>>>>> above the folder/page -> menu concept. AFAIK its way more
>>>>>>>> flexible and
>>>>>>>> probably much easier to understand for a user.
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>> And, it isn't that different from the J1 implementation. Recreating
>>>>>>>> the current J1 features for J2 will be relatively easier to do I
>>>>>>>> think.
>>>>>>>>
>>>>>>>> Note: I know the folder concept is not *just* about menus. I'm not
>>>>>>>> opposed to folders in anyway. I just think its
>>>>>>>> to restricted for menu rendering.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Can we support both, or is that too confusing to the end user?
>>>>>>> See 4 for the menu xml syntax:
>>>>>>>
>>>>>>> <menu type='folder' url='/myfolder'/>
>>>>>>>
>>>>>>> which would generate a menu based on a folder
>>>>>>>
>>>>>>
>>>>>> +1. I'm all for folder support on this. But not to be restricted
>>>>>> by it.
>>>>>>
>>>>>
>>>>> 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).
>>>>>
>>>>>
>>>>
>>>> This sounds reasonable for folders.
>>>> When the user navigates to a folder, they get the default menu for
>>>> that folder, all nodes within that folder.
>>>>
>>>> However, how would you put a menu on a page?
>>>> This could be solved by not differentiating between folders and
>>>> pages, and treat them all alike.
>>>> Whereas many systems treat pages as leaf nodes, PSML pages could be
>>>> considered as non-leaf nodes like folders.
>>>>
>>>>
>>>>
>>>>> Next we introduce the idea of a navigation renderer that would consume
>>>>> and render either .menu files OR folder/page structures. 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.
>>>>>
>>>>> The navigation renderer gives us a very fine grained control over
>>>>> how we
>>>>> render our navigation and separates the model (.menu or folders) from
>>>>> the view.
>>>>>
>>>>> Custom ordering of navigation could be done by storing item order in
>>>>> user preferences.
>>>>>
>>>
>>> Why introducing .menu files if it could be defined in a folder? I
>>> prefer to keep the syntax as simple as possible.
>>>
>>
>> +1
>>
>>
>>>> Where is the renderer defined, in the fragment or menu?
>>>> This seems very cool but a bit complicated
>>>>
>>
>> Neither, since rendering is a look and feel/view concern you would code
>> it directly into the layout template, i.e. directly into
>> decorations/layout/jetspeed/jetspeed_top.vm
>>
>>
>>
>>>> The part that Im trying to solve is how can the user clearly define
>>>> menus
>>>> If we are introducing renderers and implementation details into the
>>>> mix, I think it confuses the simplicity of the model
>>>>
>>>
>>> I agree that the mix of rendering and implementation is a bit too
>>> complicated. Different levels of rendering migth confuse more than it
>>> helps to create menus.
>>>
>>
>>
>> How about adding 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.
>>
>>
>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Roger Ruttimann <ro...@apache.org>.
Scott T Weaver wrote:
>On Thu, 2004-06-17 at 11:25, Roger Ruttimann wrote:
>
>
>>David Sean Taylor wrote:
>>
>>
>>
>>>On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote:
>>>
>>>
>>>
>>>>On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
>>>>
>>>>
>>>>
>>>>>David Sean Taylor wrote:
>>>>>
>>>>>
>>>>>
>>>>>>On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>To me, this seems to lead to very complex psml though. I would
>>>>>>>certainly like to see a more
>>>>>>>simple model implemented first before going that road.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>Im -1 on nested pages, and +1 on nested fragments (references), which
>>>>>>does not need to be implemented in the first solution
>>>>>>
>>>>>>
>>>>>+1
>>>>>
>>>>>
>>>>Also -1 on nested pages.
>>>>
>>>>
>>>>
>>>>>Nested fragments, but not as references, are already used by the
>>>>>layout portlets!
>>>>>
>>>>>
>>>>I would also like to add support for non-portlet fragments, like raw
>>>>html, etc.
>>>>
>>>>
>>>That would just be a different fragment type, such as "markup"
>>>These markup fragments will need a deployable model, like decorators
>>>It first it would seem we lose all the benefits of a portal if we put
>>>in HTML-specific markup,
>>>On the other hand, if your PSML pages were markup specific, like what
>>>J1 currently supports, it makes more sense
>>>
>>>
>>>
>>>>>>>Probably the same result could be created without page nesting using
>>>>>>>fragment references. These could
>>>>>>>reference other pages (pulling in their decorator definitions with
>>>>>>>them) or fragments within other pages.
>>>>>>>As far as I can tell, then there would be no need to define pages
>>>>>>>within pages.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Fragments do not need to be associated with a page, at least not in a
>>>>>>database implementation
>>>>>>See the database model for PSML in the J2 CVS
>>>>>>
>>>>>>
>>>>>I think if we are going to support non-page based fragments (for
>>>>>references)
>>>>>we should also provide a file based implementation. Dunno if you
>>>>>should still
>>>>>call it psml then though.
>>>>>
>>>>>
>>>>Believe it or not, I am beginning to think the non-RDBMS XML file-based
>>>>page system is a better approach than the RDBMS one. It fits better
>>>>into CMS model than an RDBMS page manager does. We could also use VFS
>>>>to abstract the file system were the pages reside. VFS also supports a
>>>>WebDAV based file system out the box.
>>>>
>>>>
>>>>
>>>Well it does make some sense and certainly simplifies things
>>>RDMBS PSML can just be an implementation for those who need it. It
>>>doesn't need to be implemented first.
>>>
>>>
>>+1 Since it is more likely that JCMS will manage the pages.
>>
>>
>>
>>>For scalable systems, from my experience a more robust Page Manager
>>>will be required than simply putting the pages on the file system
>>>with no sharing across nodes
>>>
>>>With WebDAV interfaces, we could push all of that logic (locking,
>>>versioning) back to the CMS Server and not have to deal with it
>>>That is one of the goals of JCMS
>>>Perhaps we should look into a VFS-backed JCMS for the WebDAV support
>>>
>>>I will try to work on getting JCMS into incubator so that people can
>>>look at it
>>>The current base system has a small footprint, and I'd still prefer it
>>>to go into J2 as a component
>>>
>>>
>>>
>>>
>>>>>>I believe the page within a page concept can be easily supported
>>>>>>via the
>>>>>>profiler's portal URI space, a CMS-like tree
>>>>>>
>>>>>>
>>>>>Using folder semantics you mean? Then I'm +1.
>>>>>
>>>>>
>>>>I also think the folder metaphor is the best approach.
>>>>
>>>>
>>>>
>>>>>>>- Folder or menu elements
>>>>>>>The Folder concept containing other folders and/or pages could be
>>>>>>>used
>>>>>>>to generate menus as proposed by Scott (see 4).
>>>>>>>Something I'm missing right now is a clear understanding how/where
>>>>>>>folders are defined. I found the om impl but no usage
>>>>>>>yet so its something I can't relate to enough yet to really decide if
>>>>>>>I'm going to like it or not.
>>>>>>>
>>>>>>>
>>>>>>Couldn't the Page Manager support the concept of folders in its model?
>>>>>>Im also wondering if the Page Manager should support the JCMS API
>>>>>>
>>>>>>
>>>>>One thing at a time please ;-)
>>>>>Do I understand it now correctly that folders (for a file based Page
>>>>>Manager)
>>>>>are simply derived from filesystem folders?
>>>>>
>>>>>
>>>>That is how I see it. Or possibly using a VFS file system.
>>>>
>>>>
>>>>
>>>Im still not convinced that VFS should be coupled to Jetspeed
>>>Prefer coupling at the JCMS level
>>>I will get some interfaces out on the web today for review
>>>
>>>
>>>
>>>>>So no definition needed in the psml.
>>>>>Of course, a DB Page Manager would still require explicit folder
>>>>>configuration.
>>>>>
>>>>>
>>>>That is why I am leaning more towards a page-based system.
>>>>
>>>>
>>>>
>>>>>If we have folders and pages can't JCMS support be added then "on
>>>>>top" later?
>>>>>
>>>>>
>>>>+1. JCMS may over complicate things in in the beginning.
>>>>
>>>>
>>>>
>>>I don't think so, review the interfaces first before passing judgment ;)
>>>
>>>
>Well, JCMS is just one more thing end users will have to get their head
>around before they can start using Jetspeed 2. I really don't know how
>I feel about that. I would be persuaded if some would step up and write
>some good user docs on how to the two work together.
>
>
The two components (page/menu & JCMS) could be developed independently.
Once the features are stable the page/menus could be integrated into
JCMS. Reducing the dependencies for the initial implementation helps to
speed up the J2 development.
>
>
>>If we decide to use folders/files structures for the page/menu
>>implementation the JCMS integration could be done in parallel while the
>>PSML-2 & rendering is implemented. The definition and the inital
>>implementation of the inital pages/menu implementation should not be
>>dependent on JCMS.
>>
>>
>>
>>>>>>>One important issue I would have with it though is that it wouldn't
>>>>>>>allow me to render page fragments/portlets in a menu, not external
>>>>>>>links.
>>>>>>>Likewise, I don't see how a TabbedPane could be rendered for the
>>>>>>>current page using the folder
>>>>>>>concept.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>I believe the tabbed pane could automatically pick up the folder's
>>>>>>children nodes as its menu options
>>>>>>This is a valid use case, but not the only use case
>>>>>>
>>>>>>
>>>>>I meant in this case a TabbedPane displaying fragments defined
>>>>>*within* a page.
>>>>>
>>>>>
>>>>I don't I like idea of navigating "within" a page. A page should be
>>>>your final stop, all fragments being rendered at once.
>>>>
>>>>
>>>The ability to navigate within a page was a popular feature in J1 (the
>>>impl caused me endless headaches)
>>>For example, nested menus where only the selected portlet from the
>>>fragment set is displayed and all
>>>other portlets are hidden
>>>
>>>I think we could leverage the portlet API to achieve the same thing,
>>>through maximize mode
>>>Although nesting maximized portlets is not really supported
>>>
>>>
>>>
>>>>>You won't have a folder then.
>>>>>
>>>>>
>>>>>
>>>>>>What about external links, links to other pages...
>>>>>>Or perhaps the folder is how someone defines a menu
>>>>>>
>>>>>>
>>>>What about having a special link file that you drop into a folder? Just
>>>>a plain text file with url in it. You could even go as far as dropping
>>>>velocity template into a folder to support more complicated menu items
>>>>and such.
>>>>
>>>>
>>>>
>>>For a external link, I think a menu definition is simpler and easier
>>>to understand
>>>This does sound intriguing though, each menu option could have its own
>>>decorations and style
>>>
>>>
>>>
>>>>>>>The other proposal from David Taylor was defining new psml menu and
>>>>>>>menu-item elements which could reference pages, (external) fragments
>>>>>>>and external links (see 3).
>>>>>>>I understand Scott didn't like adding additional data structures into
>>>>>>>the mix (see 4), but I for one would prefer this
>>>>>>>above the folder/page -> menu concept. AFAIK its way more flexible
>>>>>>>and
>>>>>>>probably much easier to understand for a user.
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>>>>And, it isn't that different from the J1 implementation. Recreating
>>>>>>>the current J1 features for J2 will be relatively easier to do I
>>>>>>>think.
>>>>>>>
>>>>>>>Note: I know the folder concept is not *just* about menus. I'm not
>>>>>>>opposed to folders in anyway. I just think its
>>>>>>>to restricted for menu rendering.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>Can we support both, or is that too confusing to the end user?
>>>>>>See 4 for the menu xml syntax:
>>>>>>
>>>>>><menu type='folder' url='/myfolder'/>
>>>>>>
>>>>>>which would generate a menu based on a folder
>>>>>>
>>>>>>
>>>>>+1. I'm all for folder support on this. But not to be restricted by it.
>>>>>
>>>>>
>>>>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).
>>>>
>>>>
>>>>
>>>This sounds reasonable for folders.
>>>When the user navigates to a folder, they get the default menu for
>>>that folder, all nodes within that folder.
>>>
>>>However, how would you put a menu on a page?
>>>This could be solved by not differentiating between folders and pages,
>>>and treat them all alike.
>>>Whereas many systems treat pages as leaf nodes, PSML pages could be
>>>considered as non-leaf nodes like folders.
>>>
>>>
>>>
>>>>Next we introduce the idea of a navigation renderer that would consume
>>>>and render either .menu files OR folder/page structures. 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.
>>>>
>>>>The navigation renderer gives us a very fine grained control over how we
>>>>render our navigation and separates the model (.menu or folders) from
>>>>the view.
>>>>
>>>>Custom ordering of navigation could be done by storing item order in
>>>>user preferences.
>>>>
>>>>
>>Why introducing .menu files if it could be defined in a folder? I prefer
>>to keep the syntax as simple as possible.
>>
>>
>+1
>
>
>>>Where is the renderer defined, in the fragment or menu?
>>>This seems very cool but a bit complicated
>>>
>>>
>Neither, since rendering is a look and feel/view concern you would code
>it directly into the layout template, i.e. directly into
>decorations/layout/jetspeed/jetspeed_top.vm
>
>
>
>>>The part that Im trying to solve is how can the user clearly define menus
>>>If we are introducing renderers and implementation details into the
>>>mix, I think it confuses the simplicity of the model
>>>
>>>
>>I agree that the mix of rendering and implementation is a bit too
>>complicated. Different levels of rendering migth confuse more than it
>>helps to create menus.
>>
>>
>
>How about adding 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.
>
>
>
>>
>>
>>---------------------------------------------------------------------
>>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
Re: [J2] Menu implementation
Posted by Roger Ruttimann <ro...@apache.org>.
David Sean Taylor wrote:
>
> On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote:
>
>> On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
>>
>>> David Sean Taylor wrote:
>>>
>>>>
>>>> On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
>>>>
>>>>
>>>>
>>>>> To me, this seems to lead to very complex psml though. I would
>>>>> certainly like to see a more
>>>>> simple model implemented first before going that road.
>>>>>
>>>> Im -1 on nested pages, and +1 on nested fragments (references), which
>>>> does not need to be implemented in the first solution
>>>
>>> +1
>>
>> Also -1 on nested pages.
>>
>>> Nested fragments, but not as references, are already used by the
>>> layout portlets!
>>
>> I would also like to add support for non-portlet fragments, like raw
>> html, etc.
>
> That would just be a different fragment type, such as "markup"
> These markup fragments will need a deployable model, like decorators
> It first it would seem we lose all the benefits of a portal if we put
> in HTML-specific markup,
> On the other hand, if your PSML pages were markup specific, like what
> J1 currently supports, it makes more sense
>
>>>
>>>>
>>>>> Probably the same result could be created without page nesting using
>>>>> fragment references. These could
>>>>> reference other pages (pulling in their decorator definitions with
>>>>> them) or fragments within other pages.
>>>>> As far as I can tell, then there would be no need to define pages
>>>>> within pages.
>>>>
>>>>
>>>>
>>>> Fragments do not need to be associated with a page, at least not in a
>>>> database implementation
>>>> See the database model for PSML in the J2 CVS
>>>
>>> I think if we are going to support non-page based fragments (for
>>> references)
>>> we should also provide a file based implementation. Dunno if you
>>> should still
>>> call it psml then though.
>>
>>
>> Believe it or not, I am beginning to think the non-RDBMS XML file-based
>> page system is a better approach than the RDBMS one. It fits better
>> into CMS model than an RDBMS page manager does. We could also use VFS
>> to abstract the file system were the pages reside. VFS also supports a
>> WebDAV based file system out the box.
>>
> Well it does make some sense and certainly simplifies things
> RDMBS PSML can just be an implementation for those who need it. It
> doesn't need to be implemented first.
+1 Since it is more likely that JCMS will manage the pages.
>
> For scalable systems, from my experience a more robust Page Manager
> will be required than simply putting the pages on the file system
> with no sharing across nodes
>
> With WebDAV interfaces, we could push all of that logic (locking,
> versioning) back to the CMS Server and not have to deal with it
> That is one of the goals of JCMS
> Perhaps we should look into a VFS-backed JCMS for the WebDAV support
>
> I will try to work on getting JCMS into incubator so that people can
> look at it
> The current base system has a small footprint, and I'd still prefer it
> to go into J2 as a component
>
>
>>>
>>>>
>>>> I believe the page within a page concept can be easily supported
>>>> via the
>>>> profiler's portal URI space, a CMS-like tree
>>>
>>> Using folder semantics you mean? Then I'm +1.
>>
>> I also think the folder metaphor is the best approach.
>>
>>>>
>>>>>
>>>>> - Folder or menu elements
>>>>> The Folder concept containing other folders and/or pages could be
>>>>> used
>>>>> to generate menus as proposed by Scott (see 4).
>>>>> Something I'm missing right now is a clear understanding how/where
>>>>> folders are defined. I found the om impl but no usage
>>>>> yet so its something I can't relate to enough yet to really decide if
>>>>> I'm going to like it or not.
>>>>
>
>>>> Couldn't the Page Manager support the concept of folders in its model?
>>>> Im also wondering if the Page Manager should support the JCMS API
>>>
>>> One thing at a time please ;-)
>>> Do I understand it now correctly that folders (for a file based Page
>>> Manager)
>>> are simply derived from filesystem folders?
>>
>> That is how I see it. Or possibly using a VFS file system.
>>
>
> Im still not convinced that VFS should be coupled to Jetspeed
> Prefer coupling at the JCMS level
> I will get some interfaces out on the web today for review
>
>>> So no definition needed in the psml.
>>> Of course, a DB Page Manager would still require explicit folder
>>> configuration.
>>
>> That is why I am leaning more towards a page-based system.
>>
>
>>>
>>> If we have folders and pages can't JCMS support be added then "on
>>> top" later?
>>
>> +1. JCMS may over complicate things in in the beginning.
>>
> I don't think so, review the interfaces first before passing judgment ;)
If we decide to use folders/files structures for the page/menu
implementation the JCMS integration could be done in parallel while the
PSML-2 & rendering is implemented. The definition and the inital
implementation of the inital pages/menu implementation should not be
dependent on JCMS.
>
>>>
>>>>
>>>>> One important issue I would have with it though is that it wouldn't
>>>>> allow me to render page fragments/portlets in a menu, not external
>>>>> links.
>>>>> Likewise, I don't see how a TabbedPane could be rendered for the
>>>>> current page using the folder
>>>>> concept.
>>>>
>>>>
>>>>
>>>> I believe the tabbed pane could automatically pick up the folder's
>>>> children nodes as its menu options
>>>> This is a valid use case, but not the only use case
>>>
>>> I meant in this case a TabbedPane displaying fragments defined
>>> *within* a page.
>>
>> I don't I like idea of navigating "within" a page. A page should be
>> your final stop, all fragments being rendered at once.
>
>
> The ability to navigate within a page was a popular feature in J1 (the
> impl caused me endless headaches)
> For example, nested menus where only the selected portlet from the
> fragment set is displayed and all
> other portlets are hidden
>
> I think we could leverage the portlet API to achieve the same thing,
> through maximize mode
> Although nesting maximized portlets is not really supported
>
>>
>>> You won't have a folder then.
>>>
>>>> What about external links, links to other pages...
>>>> Or perhaps the folder is how someone defines a menu
>>>
>> What about having a special link file that you drop into a folder? Just
>> a plain text file with url in it. You could even go as far as dropping
>> velocity template into a folder to support more complicated menu items
>> and such.
>>
> For a external link, I think a menu definition is simpler and easier
> to understand
> This does sound intriguing though, each menu option could have its own
> decorations and style
>
>>>>
>>>>>
>>>>> The other proposal from David Taylor was defining new psml menu and
>>>>> menu-item elements which could reference pages, (external) fragments
>>>>> and external links (see 3).
>>>>> I understand Scott didn't like adding additional data structures into
>>>>> the mix (see 4), but I for one would prefer this
>>>>> above the folder/page -> menu concept. AFAIK its way more flexible
>>>>> and
>>>>> probably much easier to understand for a user.
>>>>
>>
>>
>>>>> And, it isn't that different from the J1 implementation. Recreating
>>>>> the current J1 features for J2 will be relatively easier to do I
>>>>> think.
>>>>>
>>>>> Note: I know the folder concept is not *just* about menus. I'm not
>>>>> opposed to folders in anyway. I just think its
>>>>> to restricted for menu rendering.
>>>>>
>>>> Can we support both, or is that too confusing to the end user?
>>>> See 4 for the menu xml syntax:
>>>>
>>>> <menu type='folder' url='/myfolder'/>
>>>>
>>>> which would generate a menu based on a folder
>>>
>>> +1. I'm all for folder support on this. But not to be restricted by it.
>>
>>
>> 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).
>>
> This sounds reasonable for folders.
> When the user navigates to a folder, they get the default menu for
> that folder, all nodes within that folder.
>
> However, how would you put a menu on a page?
> This could be solved by not differentiating between folders and pages,
> and treat them all alike.
> Whereas many systems treat pages as leaf nodes, PSML pages could be
> considered as non-leaf nodes like folders.
>
>> Next we introduce the idea of a navigation renderer that would consume
>> and render either .menu files OR folder/page structures. 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.
>>
>> The navigation renderer gives us a very fine grained control over how we
>> render our navigation and separates the model (.menu or folders) from
>> the view.
>>
>> Custom ordering of navigation could be done by storing item order in
>> user preferences.
>
Why introducing .menu files if it could be defined in a folder? I prefer
to keep the syntax as simple as possible.
>>
>
> Where is the renderer defined, in the fragment or menu?
> This seems very cool but a bit complicated
>
> The part that Im trying to solve is how can the user clearly define menus
> If we are introducing renderers and implementation details into the
> mix, I think it confuses the simplicity of the model
I agree that the mix of rendering and implementation is a bit too
complicated. Different levels of rendering migth confuse more than it
helps to create menus.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jun 16, 2004, at 6:31 AM, Scott T Weaver wrote:
> On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
>> David Sean Taylor wrote:
>>
>>>
>>> On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
>>>
>>>
>>>
>>>> To me, this seems to lead to very complex psml though. I would
>>>> certainly like to see a more
>>>> simple model implemented first before going that road.
>>>>
>>> Im -1 on nested pages, and +1 on nested fragments (references), which
>>> does not need to be implemented in the first solution
>> +1
> Also -1 on nested pages.
>
>> Nested fragments, but not as references, are already used by the
>> layout portlets!
> I would also like to add support for non-portlet fragments, like raw
> html, etc.
That would just be a different fragment type, such as "markup"
These markup fragments will need a deployable model, like decorators
It first it would seem we lose all the benefits of a portal if we put
in HTML-specific markup,
On the other hand, if your PSML pages were markup specific, like what
J1 currently supports, it makes more sense
>>
>>>
>>>> Probably the same result could be created without page nesting using
>>>> fragment references. These could
>>>> reference other pages (pulling in their decorator definitions with
>>>> them) or fragments within other pages.
>>>> As far as I can tell, then there would be no need to define pages
>>>> within pages.
>>>
>>>
>>> Fragments do not need to be associated with a page, at least not in a
>>> database implementation
>>> See the database model for PSML in the J2 CVS
>> I think if we are going to support non-page based fragments (for
>> references)
>> we should also provide a file based implementation. Dunno if you
>> should still
>> call it psml then though.
>
> Believe it or not, I am beginning to think the non-RDBMS XML file-based
> page system is a better approach than the RDBMS one. It fits better
> into CMS model than an RDBMS page manager does. We could also use VFS
> to abstract the file system were the pages reside. VFS also supports a
> WebDAV based file system out the box.
>
Well it does make some sense and certainly simplifies things
RDMBS PSML can just be an implementation for those who need it. It
doesn't need to be implemented first.
For scalable systems, from my experience a more robust Page Manager
will be required than simply putting the pages on the file system
with no sharing across nodes
With WebDAV interfaces, we could push all of that logic (locking,
versioning) back to the CMS Server and not have to deal with it
That is one of the goals of JCMS
Perhaps we should look into a VFS-backed JCMS for the WebDAV support
I will try to work on getting JCMS into incubator so that people can
look at it
The current base system has a small footprint, and I'd still prefer it
to go into J2 as a component
>>
>>>
>>> I believe the page within a page concept can be easily supported via
>>> the
>>> profiler's portal URI space, a CMS-like tree
>> Using folder semantics you mean? Then I'm +1.
> I also think the folder metaphor is the best approach.
>
>>>
>>>>
>>>> - Folder or menu elements
>>>> The Folder concept containing other folders and/or pages could be
>>>> used
>>>> to generate menus as proposed by Scott (see 4).
>>>> Something I'm missing right now is a clear understanding how/where
>>>> folders are defined. I found the om impl but no usage
>>>> yet so its something I can't relate to enough yet to really decide
>>>> if
>>>> I'm going to like it or not.
>>> Couldn't the Page Manager support the concept of folders in its
>>> model?
>>> Im also wondering if the Page Manager should support the JCMS API
>> One thing at a time please ;-)
>> Do I understand it now correctly that folders (for a file based Page
>> Manager)
>> are simply derived from filesystem folders?
> That is how I see it. Or possibly using a VFS file system.
>
Im still not convinced that VFS should be coupled to Jetspeed
Prefer coupling at the JCMS level
I will get some interfaces out on the web today for review
>> So no definition needed in the psml.
>> Of course, a DB Page Manager would still require explicit folder
>> configuration.
> That is why I am leaning more towards a page-based system.
>
>>
>> If we have folders and pages can't JCMS support be added then "on
>> top" later?
> +1. JCMS may over complicate things in in the beginning.
>
I don't think so, review the interfaces first before passing judgment ;)
>>
>>>
>>>> One important issue I would have with it though is that it wouldn't
>>>> allow me to render page fragments/portlets in a menu, not external
>>>> links.
>>>> Likewise, I don't see how a TabbedPane could be rendered for the
>>>> current page using the folder
>>>> concept.
>>>
>>>
>>> I believe the tabbed pane could automatically pick up the folder's
>>> children nodes as its menu options
>>> This is a valid use case, but not the only use case
>> I meant in this case a TabbedPane displaying fragments defined
>> *within* a page.
> I don't I like idea of navigating "within" a page. A page should be
> your final stop, all fragments being rendered at once.
The ability to navigate within a page was a popular feature in J1 (the
impl caused me endless headaches)
For example, nested menus where only the selected portlet from the
fragment set is displayed and all
other portlets are hidden
I think we could leverage the portlet API to achieve the same thing,
through maximize mode
Although nesting maximized portlets is not really supported
>
>> You won't have a folder then.
>>
>>> What about external links, links to other pages...
>>> Or perhaps the folder is how someone defines a menu
> What about having a special link file that you drop into a folder?
> Just
> a plain text file with url in it. You could even go as far as dropping
> velocity template into a folder to support more complicated menu items
> and such.
>
For a external link, I think a menu definition is simpler and easier to
understand
This does sound intriguing though, each menu option could have its own
decorations and style
>>>
>>>>
>>>> The other proposal from David Taylor was defining new psml menu and
>>>> menu-item elements which could reference pages, (external) fragments
>>>> and external links (see 3).
>>>> I understand Scott didn't like adding additional data structures
>>>> into
>>>> the mix (see 4), but I for one would prefer this
>>>> above the folder/page -> menu concept. AFAIK its way more flexible
>>>> and
>>>> probably much easier to understand for a user.
>
>
>>>> And, it isn't that different from the J1 implementation. Recreating
>>>> the current J1 features for J2 will be relatively easier to do I
>>>> think.
>>>>
>>>> Note: I know the folder concept is not *just* about menus. I'm not
>>>> opposed to folders in anyway. I just think its
>>>> to restricted for menu rendering.
>>>>
>>> Can we support both, or is that too confusing to the end user?
>>> See 4 for the menu xml syntax:
>>>
>>> <menu type='folder' url='/myfolder'/>
>>>
>>> which would generate a menu based on a folder
>> +1. I'm all for folder support on this. But not to be restricted by
>> it.
>
> 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).
>
This sounds reasonable for folders.
When the user navigates to a folder, they get the default menu for that
folder, all nodes within that folder.
However, how would you put a menu on a page?
This could be solved by not differentiating between folders and pages,
and treat them all alike.
Whereas many systems treat pages as leaf nodes, PSML pages could be
considered as non-leaf nodes like folders.
> Next we introduce the idea of a navigation renderer that would consume
> and render either .menu files OR folder/page structures. 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.
>
> The navigation renderer gives us a very fine grained control over how
> we
> render our navigation and separates the model (.menu or folders) from
> the view.
>
> Custom ordering of navigation could be done by storing item order in
> user preferences.
Where is the renderer defined, in the fragment or menu?
This seems very cool but a bit complicated
The part that Im trying to solve is how can the user clearly define
menus
If we are introducing renderers and implementation details into the
mix, I think it confuses the simplicity of the model
--
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
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
Scott T Weaver wrote:
> On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
>
>>David Sean Taylor wrote:
>>
>>
>>>On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
>>>
>>>
>>>>I've been trying to get a clear picture of what the options and
>>>>positions are about menu creation for J2.
>>>>
>>>>I'm quite lost after reviewing several sources:
>>>> - 1) current J1 impl
>>>> - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
>>>> - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
>>>> ([J2} Proposal for Layout, pages & Decorator handling in J2)
>>>> - 4) http://nagoya.apache.org/jira/browse/JS2-69
>>>> (Finalizing Portal Navigation using the Profiler)
>>>>
>>>>A few design issues needs to be addressed I think to be able to decide
>>>>on the impl. of menus.
>>>>
>>>>- Nested pages
>>>>Should these be allowed?
>>>>Part of that question is what a Page is.
>>>>The pdf (see 2) says its to be considered a Fragment.
>>>>If this is meant as a "fragment" which can be included, alright. But,
>>>>I don't see how it also can
>>>>be a "Fragment" (note the case) or why it should be made one.
>>>>
>>>>Fragments already can contain other Fragments though. This is more or
>>>>less in analogy to nested
>>>>portlets in J1 I belief.
>>>>
>>>>Maybe one reason why one would want to nest pages is to be able to
>>>>define different decoration on a nested page.
>>>>It has been suggested by Scott (see 4) to allow for the most flexible
>>>>way possible this should be possible
>>>>(even up/down overrides if needed).
>>>>
>>>
>>>I see pages as existing in a bug bucket of pages.
>>>Its up to the profiler to locate the page.
>>>The way this is implemented in J2, the profiler looks at the URL path to
>>>find the page.
>>>For example
>>>
>>>/jetspeed/portal/pam
>>>/jetspeed/portal/struts-demo
>>>
>>>Locates a page named "pam" and "struts-demo" respectively
>>>A believe that the Jetspeed Profiler should support locating pages in a
>>>CMS-like URI namespace:
>>>
>>>/jetspeed/portal/root/folder1/folder2/mypage
>>
>>I think this is already possible right now, although not really based on a "Folder" object.
>>
>>
>>>Would locate a page name "mypage" in the folder "/folder1/folder2"
>>>
>>>This does not imply that pages can be nested, and Im against nesting
>>>page as it corrupts the semantics of a page version a fragment.
>>>The page implementation should support 'nesting' or 'referencing' of
>>>fragments.
>>>A fragment should also be referenced in the portal URL, for example as a
>>>render parameter:
>>>
>>>/jetspeed/portal/folder3/page4/_r_fragment/3939
>>>
>>>
>>>
>>>>To me, this seems to lead to very complex psml though. I would
>>>>certainly like to see a more
>>>>simple model implemented first before going that road.
>>>>
>>>
>>>Im -1 on nested pages, and +1 on nested fragments (references), which
>>>does not need to be implemented in the first solution
>>
>>+1
>
> Also -1 on nested pages.
>
>
>>Nested fragments, but not as references, are already used by the layout portlets!
>
> I would also like to add support for non-portlet fragments, like raw
> html, etc.
Inside psml? That would kill capability independence for sure...
I would be -1 on that.
>
>
>>>>Probably the same result could be created without page nesting using
>>>>fragment references. These could
>>>>reference other pages (pulling in their decorator definitions with
>>>>them) or fragments within other pages.
>>>>As far as I can tell, then there would be no need to define pages
>>>>within pages.
>>>
>>>
>>>Fragments do not need to be associated with a page, at least not in a
>>>database implementation
>>>See the database model for PSML in the J2 CVS
>>
>>I think if we are going to support non-page based fragments (for references)
>>we should also provide a file based implementation. Dunno if you should still
>>call it psml then though.
>
>
> Believe it or not, I am beginning to think the non-RDBMS XML file-based
> page system is a better approach than the RDBMS one. It fits better
> into CMS model than an RDBMS page manager does. We could also use VFS
> to abstract the file system were the pages reside. VFS also supports a
> WebDAV based file system out the box.
>
>
>
>>>I believe the page within a page concept can be easily supported via the
>>>profiler's portal URI space, a CMS-like tree
>>
>>Using folder semantics you mean? Then I'm +1.
>
> I also think the folder metaphor is the best approach.
>
>
>>>>- Folder or menu elements
>>>>The Folder concept containing other folders and/or pages could be used
>>>>to generate menus as proposed by Scott (see 4).
>>>>Something I'm missing right now is a clear understanding how/where
>>>>folders are defined. I found the om impl but no usage
>>>>yet so its something I can't relate to enough yet to really decide if
>>>>I'm going to like it or not.
>>>>
>>>
>>>Couldn't the Page Manager support the concept of folders in its model?
>>>Im also wondering if the Page Manager should support the JCMS API
>>
>>One thing at a time please ;-)
>>Do I understand it now correctly that folders (for a file based Page Manager)
>>are simply derived from filesystem folders?
>
> That is how I see it. Or possibly using a VFS file system.
>
>
>>So no definition needed in the psml.
>>Of course, a DB Page Manager would still require explicit folder configuration.
>
> That is why I am leaning more towards a page-based system.
>
>
>>If we have folders and pages can't JCMS support be added then "on top" later?
>
> +1. JCMS may over complicate things in in the beginning.
>
>
>>>>One important issue I would have with it though is that it wouldn't
>>>>allow me to render page fragments/portlets in a menu, not external links.
>>>>Likewise, I don't see how a TabbedPane could be rendered for the
>>>>current page using the folder
>>>>concept.
>>>
>>>
>>>I believe the tabbed pane could automatically pick up the folder's
>>>children nodes as its menu options
>>>This is a valid use case, but not the only use case
>>
>>I meant in this case a TabbedPane displaying fragments defined *within* a page.
>
> I don't I like idea of navigating "within" a page. A page should be
> your final stop, all fragments being rendered at once.
>
>
>>You won't have a folder then.
>>
>>
>>>What about external links, links to other pages...
>>>Or perhaps the folder is how someone defines a menu
>
> What about having a special link file that you drop into a folder? Just
> a plain text file with url in it. You could even go as far as dropping
> velocity template into a folder to support more complicated menu items
> and such.
We sure would have a hard time supporting that kind of feature through a DB
Page manager tough, or the code has to be stored "raw". But JCMS should
be able to handle that just fine.
>
>
>>>>The other proposal from David Taylor was defining new psml menu and
>>>>menu-item elements which could reference pages, (external) fragments
>>>>and external links (see 3).
>>>>I understand Scott didn't like adding additional data structures into
>>>>the mix (see 4), but I for one would prefer this
>>>>above the folder/page -> menu concept. AFAIK its way more flexible and
>>>>probably much easier to understand for a user.
>
>
>
>>>>And, it isn't that different from the J1 implementation. Recreating
>>>>the current J1 features for J2 will be relatively easier to do I think.
>>>>
>>>>Note: I know the folder concept is not *just* about menus. I'm not
>>>>opposed to folders in anyway. I just think its
>>>>to restricted for menu rendering.
>>>>
>>>
>>>Can we support both, or is that too confusing to the end user?
>>>See 4 for the menu xml syntax:
>>>
>>><menu type='folder' url='/myfolder'/>
>>>
>>>which would generate a menu based on a folder
>>
>>+1. I'm all for folder support on this. But not to be restricted by it.
>
>
> 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?
> 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 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?
>
> The navigation renderer gives us a very fine grained control over how we
> render our navigation and separates the model (.menu or folders) from
> the view.
>
> Custom ordering of navigation could be done by storing item order in
> user preferences.
>
>
>>>>I'd like some comments and if already possible a vote which way we
>>>>should go about menu rendering.
>>>>I know I'll something soon ;-)
>>>
>>>
>>>Yes well lets try to get some consensus on design first
>>
>>:-)
>>I don't want to push anything here. Consensus must be reached of course.
>>I just think its an important structural issue which already has been discussed a few
>>times before. After a certain time, its better to decide instead of keep the issue
>>dangling ...
>>
>>
>>
>>---------------------------------------------------------------------
>>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
Re: [J2] Menu implementation
Posted by Scott T Weaver <sc...@binary-designs.net>.
On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
> David Sean Taylor wrote:
>
> >
> > On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
> >
> >> I've been trying to get a clear picture of what the options and
> >> positions are about menu creation for J2.
> >>
> >> I'm quite lost after reviewing several sources:
> >> - 1) current J1 impl
> >> - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
> >> - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
> >> ([J2} Proposal for Layout, pages & Decorator handling in J2)
> >> - 4) http://nagoya.apache.org/jira/browse/JS2-69
> >> (Finalizing Portal Navigation using the Profiler)
> >>
> >> A few design issues needs to be addressed I think to be able to decide
> >> on the impl. of menus.
> >>
> >> - Nested pages
> >> Should these be allowed?
> >> Part of that question is what a Page is.
> >> The pdf (see 2) says its to be considered a Fragment.
> >> If this is meant as a "fragment" which can be included, alright. But,
> >> I don't see how it also can
> >> be a "Fragment" (note the case) or why it should be made one.
> >>
> >> Fragments already can contain other Fragments though. This is more or
> >> less in analogy to nested
> >> portlets in J1 I belief.
> >>
> >> Maybe one reason why one would want to nest pages is to be able to
> >> define different decoration on a nested page.
> >> It has been suggested by Scott (see 4) to allow for the most flexible
> >> way possible this should be possible
> >> (even up/down overrides if needed).
> >>
> > I see pages as existing in a bug bucket of pages.
> > Its up to the profiler to locate the page.
> > The way this is implemented in J2, the profiler looks at the URL path to
> > find the page.
> > For example
> >
> > /jetspeed/portal/pam
> > /jetspeed/portal/struts-demo
> >
> > Locates a page named "pam" and "struts-demo" respectively
> > A believe that the Jetspeed Profiler should support locating pages in a
> > CMS-like URI namespace:
> >
> > /jetspeed/portal/root/folder1/folder2/mypage
> I think this is already possible right now, although not really based on a "Folder" object.
>
> >
> > Would locate a page name "mypage" in the folder "/folder1/folder2"
> >
> > This does not imply that pages can be nested, and Im against nesting
> > page as it corrupts the semantics of a page version a fragment.
> > The page implementation should support 'nesting' or 'referencing' of
> > fragments.
> > A fragment should also be referenced in the portal URL, for example as a
> > render parameter:
> >
> > /jetspeed/portal/folder3/page4/_r_fragment/3939
> >
> >
> >> To me, this seems to lead to very complex psml though. I would
> >> certainly like to see a more
> >> simple model implemented first before going that road.
> >>
> > Im -1 on nested pages, and +1 on nested fragments (references), which
> > does not need to be implemented in the first solution
> +1
Also -1 on nested pages.
> Nested fragments, but not as references, are already used by the layout portlets!
I would also like to add support for non-portlet fragments, like raw
html, etc.
>
> >
> >> Probably the same result could be created without page nesting using
> >> fragment references. These could
> >> reference other pages (pulling in their decorator definitions with
> >> them) or fragments within other pages.
> >> As far as I can tell, then there would be no need to define pages
> >> within pages.
> >
> >
> > Fragments do not need to be associated with a page, at least not in a
> > database implementation
> > See the database model for PSML in the J2 CVS
> I think if we are going to support non-page based fragments (for references)
> we should also provide a file based implementation. Dunno if you should still
> call it psml then though.
Believe it or not, I am beginning to think the non-RDBMS XML file-based
page system is a better approach than the RDBMS one. It fits better
into CMS model than an RDBMS page manager does. We could also use VFS
to abstract the file system were the pages reside. VFS also supports a
WebDAV based file system out the box.
>
> >
> > I believe the page within a page concept can be easily supported via the
> > profiler's portal URI space, a CMS-like tree
> Using folder semantics you mean? Then I'm +1.
I also think the folder metaphor is the best approach.
> >
> >>
> >> - Folder or menu elements
> >> The Folder concept containing other folders and/or pages could be used
> >> to generate menus as proposed by Scott (see 4).
> >> Something I'm missing right now is a clear understanding how/where
> >> folders are defined. I found the om impl but no usage
> >> yet so its something I can't relate to enough yet to really decide if
> >> I'm going to like it or not.
> >>
> > Couldn't the Page Manager support the concept of folders in its model?
> > Im also wondering if the Page Manager should support the JCMS API
> One thing at a time please ;-)
> Do I understand it now correctly that folders (for a file based Page Manager)
> are simply derived from filesystem folders?
That is how I see it. Or possibly using a VFS file system.
> So no definition needed in the psml.
> Of course, a DB Page Manager would still require explicit folder configuration.
That is why I am leaning more towards a page-based system.
>
> If we have folders and pages can't JCMS support be added then "on top" later?
+1. JCMS may over complicate things in in the beginning.
>
> >
> >> One important issue I would have with it though is that it wouldn't
> >> allow me to render page fragments/portlets in a menu, not external links.
> >> Likewise, I don't see how a TabbedPane could be rendered for the
> >> current page using the folder
> >> concept.
> >
> >
> > I believe the tabbed pane could automatically pick up the folder's
> > children nodes as its menu options
> > This is a valid use case, but not the only use case
> I meant in this case a TabbedPane displaying fragments defined *within* a page.
I don't I like idea of navigating "within" a page. A page should be
your final stop, all fragments being rendered at once.
> You won't have a folder then.
>
> > What about external links, links to other pages...
> > Or perhaps the folder is how someone defines a menu
What about having a special link file that you drop into a folder? Just
a plain text file with url in it. You could even go as far as dropping
velocity template into a folder to support more complicated menu items
and such.
> >
> >>
> >> The other proposal from David Taylor was defining new psml menu and
> >> menu-item elements which could reference pages, (external) fragments
> >> and external links (see 3).
> >> I understand Scott didn't like adding additional data structures into
> >> the mix (see 4), but I for one would prefer this
> >> above the folder/page -> menu concept. AFAIK its way more flexible and
> >> probably much easier to understand for a user.
> >> And, it isn't that different from the J1 implementation. Recreating
> >> the current J1 features for J2 will be relatively easier to do I think.
> >>
> >> Note: I know the folder concept is not *just* about menus. I'm not
> >> opposed to folders in anyway. I just think its
> >> to restricted for menu rendering.
> >>
> > Can we support both, or is that too confusing to the end user?
> > See 4 for the menu xml syntax:
> >
> > <menu type='folder' url='/myfolder'/>
> >
> > which would generate a menu based on a folder
> +1. I'm all for folder support on this. But not to be restricted by it.
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. 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.
The navigation renderer gives us a very fine grained control over how we
render our navigation and separates the model (.menu or folders) from
the view.
Custom ordering of navigation could be done by storing item order in
user preferences.
>
> >
> >> I'd like some comments and if already possible a vote which way we
> >> should go about menu rendering.
> >> I know I'll something soon ;-)
> >
> >
> > Yes well lets try to get some consensus on design first
> :-)
> I don't want to push anything here. Consensus must be reached of course.
> I just think its an important structural issue which already has been discussed a few
> times before. After a certain time, its better to decide instead of keep the issue
> dangling ...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
>
> On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
>
>> I've been trying to get a clear picture of what the options and
>> positions are about menu creation for J2.
>>
>> I'm quite lost after reviewing several sources:
>> - 1) current J1 impl
>> - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
>> - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
>> ([J2} Proposal for Layout, pages & Decorator handling in J2)
>> - 4) http://nagoya.apache.org/jira/browse/JS2-69
>> (Finalizing Portal Navigation using the Profiler)
>>
>> A few design issues needs to be addressed I think to be able to decide
>> on the impl. of menus.
>>
>> - Nested pages
>> Should these be allowed?
>> Part of that question is what a Page is.
>> The pdf (see 2) says its to be considered a Fragment.
>> If this is meant as a "fragment" which can be included, alright. But,
>> I don't see how it also can
>> be a "Fragment" (note the case) or why it should be made one.
>>
>> Fragments already can contain other Fragments though. This is more or
>> less in analogy to nested
>> portlets in J1 I belief.
>>
>> Maybe one reason why one would want to nest pages is to be able to
>> define different decoration on a nested page.
>> It has been suggested by Scott (see 4) to allow for the most flexible
>> way possible this should be possible
>> (even up/down overrides if needed).
>>
> I see pages as existing in a bug bucket of pages.
> Its up to the profiler to locate the page.
> The way this is implemented in J2, the profiler looks at the URL path to
> find the page.
> For example
>
> /jetspeed/portal/pam
> /jetspeed/portal/struts-demo
>
> Locates a page named "pam" and "struts-demo" respectively
> A believe that the Jetspeed Profiler should support locating pages in a
> CMS-like URI namespace:
>
> /jetspeed/portal/root/folder1/folder2/mypage
I think this is already possible right now, although not really based on a "Folder" object.
>
> Would locate a page name "mypage" in the folder "/folder1/folder2"
>
> This does not imply that pages can be nested, and Im against nesting
> page as it corrupts the semantics of a page version a fragment.
> The page implementation should support 'nesting' or 'referencing' of
> fragments.
> A fragment should also be referenced in the portal URL, for example as a
> render parameter:
>
> /jetspeed/portal/folder3/page4/_r_fragment/3939
>
>
>> To me, this seems to lead to very complex psml though. I would
>> certainly like to see a more
>> simple model implemented first before going that road.
>>
> Im -1 on nested pages, and +1 on nested fragments (references), which
> does not need to be implemented in the first solution
+1
Nested fragments, but not as references, are already used by the layout portlets!
>
>> Probably the same result could be created without page nesting using
>> fragment references. These could
>> reference other pages (pulling in their decorator definitions with
>> them) or fragments within other pages.
>> As far as I can tell, then there would be no need to define pages
>> within pages.
>
>
> Fragments do not need to be associated with a page, at least not in a
> database implementation
> See the database model for PSML in the J2 CVS
I think if we are going to support non-page based fragments (for references)
we should also provide a file based implementation. Dunno if you should still
call it psml then though.
>
> I believe the page within a page concept can be easily supported via the
> profiler's portal URI space, a CMS-like tree
Using folder semantics you mean? Then I'm +1.
>
>>
>> - Folder or menu elements
>> The Folder concept containing other folders and/or pages could be used
>> to generate menus as proposed by Scott (see 4).
>> Something I'm missing right now is a clear understanding how/where
>> folders are defined. I found the om impl but no usage
>> yet so its something I can't relate to enough yet to really decide if
>> I'm going to like it or not.
>>
> Couldn't the Page Manager support the concept of folders in its model?
> Im also wondering if the Page Manager should support the JCMS API
One thing at a time please ;-)
Do I understand it now correctly that folders (for a file based Page Manager)
are simply derived from filesystem folders? So no definition needed in the psml.
Of course, a DB Page Manager would still require explicit folder configuration.
If we have folders and pages can't JCMS support be added then "on top" later?
>
>> One important issue I would have with it though is that it wouldn't
>> allow me to render page fragments/portlets in a menu, not external links.
>> Likewise, I don't see how a TabbedPane could be rendered for the
>> current page using the folder
>> concept.
>
>
> I believe the tabbed pane could automatically pick up the folder's
> children nodes as its menu options
> This is a valid use case, but not the only use case
I meant in this case a TabbedPane displaying fragments defined *within* a page.
You won't have a folder then.
> What about external links, links to other pages...
> Or perhaps the folder is how someone defines a menu
>
>>
>> The other proposal from David Taylor was defining new psml menu and
>> menu-item elements which could reference pages, (external) fragments
>> and external links (see 3).
>> I understand Scott didn't like adding additional data structures into
>> the mix (see 4), but I for one would prefer this
>> above the folder/page -> menu concept. AFAIK its way more flexible and
>> probably much easier to understand for a user.
>> And, it isn't that different from the J1 implementation. Recreating
>> the current J1 features for J2 will be relatively easier to do I think.
>>
>> Note: I know the folder concept is not *just* about menus. I'm not
>> opposed to folders in anyway. I just think its
>> to restricted for menu rendering.
>>
> Can we support both, or is that too confusing to the end user?
> See 4 for the menu xml syntax:
>
> <menu type='folder' url='/myfolder'/>
>
> which would generate a menu based on a folder
+1. I'm all for folder support on this. But not to be restricted by it.
>
>> I'd like some comments and if already possible a vote which way we
>> should go about menu rendering.
>> I know I'll something soon ;-)
>
>
> Yes well lets try to get some consensus on design first
:-)
I don't want to push anything here. Consensus must be reached of course.
I just think its an important structural issue which already has been discussed a few
times before. After a certain time, its better to decide instead of keep the issue
dangling ...
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Menu implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
> I've been trying to get a clear picture of what the options and
> positions are about menu creation for J2.
>
> I'm quite lost after reviewing several sources:
> - 1) current J1 impl
> - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
> - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
> ([J2} Proposal for Layout, pages & Decorator handling in J2)
> - 4) http://nagoya.apache.org/jira/browse/JS2-69
> (Finalizing Portal Navigation using the Profiler)
>
> A few design issues needs to be addressed I think to be able to decide
> on the impl. of menus.
>
> - Nested pages
> Should these be allowed?
> Part of that question is what a Page is.
> The pdf (see 2) says its to be considered a Fragment.
> If this is meant as a "fragment" which can be included, alright. But,
> I don't see how it also can
> be a "Fragment" (note the case) or why it should be made one.
>
> Fragments already can contain other Fragments though. This is more or
> less in analogy to nested
> portlets in J1 I belief.
>
> Maybe one reason why one would want to nest pages is to be able to
> define different decoration on a nested page.
> It has been suggested by Scott (see 4) to allow for the most flexible
> way possible this should be possible
> (even up/down overrides if needed).
>
I see pages as existing in a bug bucket of pages.
Its up to the profiler to locate the page.
The way this is implemented in J2, the profiler looks at the URL path
to find the page.
For example
/jetspeed/portal/pam
/jetspeed/portal/struts-demo
Locates a page named "pam" and "struts-demo" respectively
A believe that the Jetspeed Profiler should support locating pages in a
CMS-like URI namespace:
/jetspeed/portal/root/folder1/folder2/mypage
Would locate a page name "mypage" in the folder "/folder1/folder2"
This does not imply that pages can be nested, and Im against nesting
page as it corrupts the semantics of a page version a fragment.
The page implementation should support 'nesting' or 'referencing' of
fragments.
A fragment should also be referenced in the portal URL, for example as
a render parameter:
/jetspeed/portal/folder3/page4/_r_fragment/3939
> To me, this seems to lead to very complex psml though. I would
> certainly like to see a more
> simple model implemented first before going that road.
>
Im -1 on nested pages, and +1 on nested fragments (references), which
does not need to be implemented in the first solution
> Probably the same result could be created without page nesting using
> fragment references. These could
> reference other pages (pulling in their decorator definitions with
> them) or fragments within other pages.
> As far as I can tell, then there would be no need to define pages
> within pages.
Fragments do not need to be associated with a page, at least not in a
database implementation
See the database model for PSML in the J2 CVS
I believe the page within a page concept can be easily supported via
the profiler's portal URI space, a CMS-like tree
>
> - Folder or menu elements
> The Folder concept containing other folders and/or pages could be used
> to generate menus as proposed by Scott (see 4).
> Something I'm missing right now is a clear understanding how/where
> folders are defined. I found the om impl but no usage
> yet so its something I can't relate to enough yet to really decide if
> I'm going to like it or not.
>
Couldn't the Page Manager support the concept of folders in its model?
Im also wondering if the Page Manager should support the JCMS API
> One important issue I would have with it though is that it wouldn't
> allow me to render page fragments/portlets in a menu, not external
> links.
> Likewise, I don't see how a TabbedPane could be rendered for the
> current page using the folder
> concept.
I believe the tabbed pane could automatically pick up the folder's
children nodes as its menu options
This is a valid use case, but not the only use case
What about external links, links to other pages...
Or perhaps the folder is how someone defines a menu
>
> The other proposal from David Taylor was defining new psml menu and
> menu-item elements which could reference pages, (external) fragments
> and external links (see 3).
> I understand Scott didn't like adding additional data structures into
> the mix (see 4), but I for one would prefer this
> above the folder/page -> menu concept. AFAIK its way more flexible and
> probably much easier to understand for a user.
> And, it isn't that different from the J1 implementation. Recreating
> the current J1 features for J2 will be relatively easier to do I
> think.
>
> Note: I know the folder concept is not *just* about menus. I'm not
> opposed to folders in anyway. I just think its
> to restricted for menu rendering.
>
Can we support both, or is that too confusing to the end user?
See 4 for the menu xml syntax:
<menu type='folder' url='/myfolder'/>
which would generate a menu based on a folder
> I'd like some comments and if already possible a vote which way we
> should go about menu rendering.
> I know I'll something soon ;-)
Yes well lets try to get some consensus on design first
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org