portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott T Weaver <scotts-jetspeed-l...@binary-designs.net>
Subject Re: [J2] Menu implementation
Date Wed, 23 Jun 2004 13:10:17 GMT
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: 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
-- 
******************************************
*           Scott T. Weaver              *
*         <weaver@apache.org>            *
*     <http://www.einnovation.com>       *   
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message