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...
It's already optional :-)
*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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
