4 Aug
2009
4 Aug
'09
6:53 p.m.
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.
* Introduce the MacroCategoriesManager component with following methods:
List<String> getMacroCategories()
List<String> getMacroNames(String category)
List<String> getMacroNames(String category, Syntax syntax)
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
5 Aug
5 Aug
2:35 p.m.
On Tue, Aug 4, 2009 at 18:53, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
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
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
7:30 p.m.
Hi,
On Wed, Aug 5, 2009 at 6:05 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Tue, Aug 4, 2009 at 18:53, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
The other sensible way to indicate a macro without a category is to return
"null" in getCategory() method. But the problem with this is it is hard to
expose such macros through MacroCategoriesManager in a sensible way:
* We could have a Set<String> getMacrosWithoutCategory() method
* Or we can allow client code to pass "null" as an argument to
getMacroNames(String category) method.
IMO the second method is not explicit enough and the first method seems like
an overkill.
WDYT?
Thanks.
- Asiri
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6 Aug
6 Aug
12:10 p.m.
On Wed, Aug 5, 2009 at 19:30, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
Hi,
On Wed, Aug 5, 2009 at 6:05 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
I think both solutions are better than some random String which make
impossible to know that a macro does not have category.
On Tue, Aug 4, 2009 at 18:53, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
The other sensible way to indicate a macro without a category is to return
"null" in getCategory() method. But the problem with this is it is hard to
expose such macros through MacroCategoriesManager in a sensible way:
* We could have a Set<String> getMacrosWithoutCategory() method
* Or we can allow client code to pass "null" as an argument to
getMacroNames(String category) method.
IMO the second method is not explicit enough and the first method seems like
an overkill.
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.
WDYT?
Thanks.
- Asiri
--
Thomas Mortagne
Just to make sure since it's not very clear in your proposal.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
* 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5523
days inactive
5525
days old
4 comments
2 participants
participants (2)
-
Asiri Rathnayake -
Thomas Mortagne