portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] Menu implementation
Date Wed, 23 Jun 2004 02:56:49 GMT

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" <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
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

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

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

View raw message