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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
