Re: [J2] Menu implementation

Tue, 22 Jun 2004 19:57:16 -0700 


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






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
[office]   +01 707 773-4646
[mobile] +01 707 529 9194



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to