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 > Survey says: c ;)
> > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
