portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stijn de Witt" <Stijn.deW...@bergland-it.nl>
Subject Re: [J2] Menu implementation
Date Tue, 22 Jun 2004 22:21:15 GMT

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" <ate@douma.nu>
To: "Jetspeed Developers List" <jetspeed-dev@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
> 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"
>        <!-- specify as default topmenu menu decorator a pulldownmenu with
an marine menu decoration -->
>        <decorator id="pulldownmenu"  type="menu"    value="topmenu"
>        <!-- override the default decoration on the leftmenu menu decorator
for this folder -->
>        <decorator               type="menu"    value="leftmenu"
>        <!-- default disable the rightmenu decorator for this folder -->
>        <decorator               type="menu"    value="rightmenu"
>        <!-- specify as default portlet decorator the jetspeed portlet
decorator with jetspeed-blue decoration-->
>        <decorator id="jetspeed" type="portlet" value="default"
>      </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"
>        <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
> > 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

View raw message