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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
******************************************
* Scott T. Weaver *
* <[EMAIL PROTECTED]> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
