Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Message-ID: <40D87356.9070502@douma.nu>
Date: Tue, 22 Jun 2004 19:58:46 +0200
From: Ate Douma <ate@douma.nu>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@jakarta.apache.org>
Subject: Re: [J2] Menu implementation
References: <40CF1B72.8090307@douma.nu>
In-Reply-To: <40CF1B72.8090307@douma.nu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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