Return-Path: 
 <jetspeed-dev-return-15874-apmail-jakarta-jetspeed-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-jetspeed-dev-archive@www.apache.org
Received: (qmail 25972 invoked from network); 23 Jun 2004 10:51:56 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 23 Jun 2004 10:51:56 -0000
Received: (qmail 48166 invoked by uid 500); 23 Jun 2004 10:44:55 -0000
Delivered-To: apmail-jakarta-jetspeed-dev-archive@jakarta.apache.org
Received: (qmail 37631 invoked by uid 500); 23 Jun 2004 10:41:13 -0000
Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:jetspeed-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:jetspeed-dev-help@jakarta.apache.org>
List-Post: <mailto:jetspeed-dev@jakarta.apache.org>
List-Id: "Jetspeed Developers List" <jetspeed-dev.jakarta.apache.org>
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Delivered-To: mailing list jetspeed-dev@jakarta.apache.org
Received: (qmail 27930 invoked by uid 99); 23 Jun 2004 10:37:03 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [62.212.76.62] (HELO server.by008.net) (62.212.76.62)
  by apache.org (qpsmtpd/0.27.1) with ESMTP; Wed, 23 Jun 2004 03:37:03 -0700
Received: from adouma.demon.nl ([82.161.89.203] helo=[127.0.0.1])
	by server.by008.net with asmtp (Exim 4.34)
	id 1Bd57o-0003Iz-Gr; Wed, 23 Jun 2004 12:37:04 +0200
Message-ID: <40D95D45.6070608@douma.nu>
Date: Wed, 23 Jun 2004 12:36:53 +0200
From: Ate Douma <ate@douma.nu>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
X-Accept-Language: en
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@jakarta.apache.org>
Subject: Re: [J2] Menu implementation
References: <40CF1B72.8090307@douma.nu> <40D87356.9070502@douma.nu>
In-Reply-To: <40D87356.9070502@douma.nu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.by008.net
X-AntiAbuse: Original Domain - jakarta.apache.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - douma.nu
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

I'd like to add a few comments to my proposal concerning the elements section of my example (some of which
came up yesterday during a chat I had with David Sean Taylor).

Here's the elements section again:

     <!-- 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>

In my example all the elements for a menu node are specified, including those not to be displayed
(hidden). The 'hidden' elements really are redundant in this example if all elements are to be specified.
So you can just leave them out.

But, you still need to specify all which should be displayed. Furthermore, the order in which they are
displayed is derived from it.

One issue from the previous discussions was that we really should provide a intuitive and easy menu configuration.
Although I think my proposal is very powerfull, it still requires a lot of configuration (but far less then what's needed in J1).

Maybe different strategies can be defined for deriving the elements, and their order, so the elements section isn't
always, or not at all, needed.
One way could be allowing 'hidden' and 'order' attributes on Page and Folder configurations.
Still, Link and element references will have to be defined. Maybe it could be done in separate configurations (files) instead
of bundling them in one. Don't know if that would be an improvement though.

Concerning the 'intuitive' menu definition issue: maybe what is needed is a change of view.
In J1 you won't have a menu unless you define it (completely) on every page which needs one.
Using this proposal, you usually have a standard menu definition (tabmenu on the top, tree menu on the left or something similar).
Only thing needed is a proper menu node configuration instead of a complete definition.
By default, a new Page could be automatically included in a menu unless it is made 'hidden'. It really is more a question of in which folder 
the Page should go to get it in the correct menu.
And using Links and Page or Folder references is simply adding them to the correct folder to get them included.
With Links and references the site navigation can be defined 'on top' of the folder structure.

Regards,

Ate


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