5 Aug
2009
5 Aug
'09
6:55 p.m.
On Wed, Aug 5, 2009 at 14:35, Thomas Mortagne<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Tue, Aug 4, 2009 at 18:53, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
Actually forget that, i did not remember that Macro does not know its own name.
Hi,
I would like to introduce a MacroCategoriesManager component for managing
macro categories. We already have a MacroManager component in place but I
think seperating out the concern of macro categories management into a
seperate component creates a more extensible design. Following is a basic
outline for implementing MacroCategoriesManager component:
* Introduce MacroDescriptor::getDefaultCategory() method which returns a
String. The purpose of this method is to allow macro author to supply a
default category under which his macro should be listed. This method can
virtually return any string.
Following three steps I'm not very confident about:
* Duplicate each existing constructor in AbstractMacro and add a 'category'
parameter.
* Make AbstractMacroDescriptor constructor accept a 'category' parameter.
* Duplicate each existing constructor in DefaultMacroDescriptor and add a
'category' parameter.
If a macro author does not specify a default category, the "Other" category
will be used.
Where do you plan to decide for "Other" string ? IMO it's should not
be the default value of the field containing the category in
AbtractMacro, you should know that a macro did not defined any
category to let the user of the api decide what it does with macro
without category, the way we do in the WYSIYWG is just one way, you
could decide that a macro without category is not listed or is listed
visualy at the same level of the categories etc... At rendering midule
level you just need to know that a macro does not have any category,
the choice of the default category is made by the presentation side.
Just to make sure since it's not very clear in your proposal.
* Introduce the MacroCategoriesManager component with following methods:
List<String> getMacroCategories()
List<String> getMacroNames(String category)
List<String> getMacroNames(String category, Syntax syntax)
Why not return a list of Macro instead of just the names ? It would be
more consistent with MacroManager.
Each of these methods will give priority to admin configured macro
categories. That is they will discard MacroDescriptor::getDefaultCategory()
return value if the wiki admin has configured a different category for a
given macro.
* A macro category can be overwritten by specifying the configuration
parameter "org.xwiki.rendering.macro.<macro_name>.category" using
xwiki's
configuration mechanism (Ex. xwiki.properties).
This is my initial design idea, please let me know what you think.
Thanks.
- Asiri
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne