Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Subject: Re: [J2] Menu implementation
From: Scott T Weaver <scotts-jetspeed-list@binary-designs.net>
To: Jetspeed Developers List <jetspeed-dev@jakarta.apache.org>
In-Reply-To: <40D98D85.3090004@douma.nu>
References: <40CF1B72.8090307@douma.nu>  <40D87356.9070502@douma.nu>
	 <1087996215.3435.26.camel@pnqnp008-und538547.net.plm.eds.com>
	 <40D98D85.3090004@douma.nu>
Content-Type: text/plain
Message-Id: <1088001464.3435.63.camel@pnqnp008-und538547.net.plm.eds.com>
Mime-Version: 1.0
Date: Wed, 23 Jun 2004 10:37:46 -0400
Content-Transfer-Encoding: 7bit

Overall, this proposal is looking great!  I think we are at stage were
we can start developing a model from a code point of view.

 Let's make sure we make heavy use of the wiki since I can already tell
this isn't going to a be a one man effort ;)

On Wed, 2004-06-23 at 10:02, Ate Douma wrote:
> Scott T Weaver wrote:
> 
> >>*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.
> +1
> 
> >>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.
> +1. It would lead to tight coupling with the Profiler though I guess...
> 
> > 
> >>*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.
> It's already optional :-)
> I described for the Page Decoration that it can contain defaults for both the Menu and Portlet decorators (see above).
> Its not uncommon that menus look quite differently from the rest of a page. Being able to change only the Menu styles 
> would be a nice feature (especially for end users) I think.
> But, its not a requirement on my side. If we don't like it: drop it.
> 
> > 
> > 
> >>*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
> Scott, I'm not sure I get what you are saying.
> 
> Could you please choose only ;-) one below:
> a) you like the separation because it will make development more complicated
> b) you like the separation because otherwise the development will be more complicated
> c) you don't like the separation because it will make development more complicated
> d) you don't like the separation because otherwise the development will be more complicated
> 
> 
> > 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.
> +1.
> 
> I'm against extensive meta-data too. This is just a first shot of an example in which I wanted to show all
> the options. I should have know this would send the wrong message without explaining it as such.
> Also, this proposal is meant as food for discussion.
> I'm not stuck to this design, I just happen to like it.
> Meta-data configuration is mostly implementation level too me. We should be able to come to an
> agreement on that afterwards. The main design concepts should first be agreed upon.
> 
> 
> 
> ---------------------------------------------------------------------
> 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