[xwiki-devs] [DISCUSSION] Macro categories
Hi all, This is about implementing back-end support for macro categories. My understanding of macro categories and it's implementation is bit vague at this point, hopefully this email will set things straight. To understand the usefulness of macro categories, have a look at confluence macro browser: http://confluence.atlassian.com/display/DOC/Working+with+the+Macro+Browser We can identify several categories by looking at confluence but XWiki will need several other categories as well. I can think of few XWiki macro categories: * Presentation - Macros that allow presenting document content with various styles. Like box & code macros * Document content - Macros that add stuff into a wiki page, like image, video & office macros. * Scripting - HTML, Velocity, Groovy, Ruby etc. * Visualization / Reporting - Chart macro and the like. * External content - Macros that fetch content from external sources. Like Rss macro. * Development - Macros in development / introductory stage. I'm pretty sure there are more categories to consider (please list them). Now for the real questions that are troubling me: * Should these categories be statically defined inside the rendering module? This would mean that the macro author gets to select which category his macro belogs to, which in turn means we should have a method like: MacroCategory getCategory() inside the Macro interface. Using this information MacroManager will present different macro categories to the outside world. * The other approach is to keep this categorization inside some wiki pages and allow administrators to manipulate it: Create / Edit categories, assign macros to categories etc. I'm not sure what problems this would create when implementing macro browser though. * Another (very hackish) approach would be to use the component role hint in the same fashion it is used to specify macros for different syntaxes. I think this is enough to get the discussion started. Thank you very much for your input. - Asiri
Hi Asiri, On Mon, Aug 3, 2009 at 5:08 PM, Asiri Rathnayake <asiri.rathnayake@gmail.com
wrote:
Hi all,
This is about implementing back-end support for macro categories. My understanding of macro categories and it's implementation is bit vague at this point, hopefully this email will set things straight.
Basically, the aim of categories is to make it easy for users to find relevant macros when they try using them. If/when the list of macros becomes too big to fit on one screen (20+ macros), using categories will make it easier to find the right macro. I think we only need one level of categories (no subcategories) as of today. This would allow us to scale approximately up to 10 categories * 8 macros = 80 macros. Once we reach that number of macros, we'll have to find additional ways to let users find macros anyway (most probably through a search in macros). To understand the usefulness of macro categories, have a look at confluence
macro browser: http://confluence.atlassian.com/display/DOC/Working+with+the+Macro+Browser
We can identify several categories by looking at confluence but XWiki will need several other categories as well. I can think of few XWiki macro categories:
* Presentation - Macros that allow presenting document content with various styles. Like box & code macros
* Document content - Macros that add stuff into a wiki page, like image, video & office macros.
+ the footnote macro * Scripting - HTML, Velocity, Groovy, Ruby etc. Could also be named "Development"
* Visualization / Reporting - Chart macro and the like.
* External content - Macros that fetch content from external sources. Like Rss macro.
* Development - Macros in development / introductory stage.
Could be renamed "under development" or "in progress". I'm not sure we want to display unfinished macros in the macro dialog box though (ideally we wouldn't), which means we'd have to let users specify whether their macro is ready for publication or not. I'm pretty sure there are more categories to consider (please list them).
Now for the real questions that are troubling me:
* Should these categories be statically defined inside the rendering module? This would mean that the macro author gets to select which category his macro belogs to, which in turn means we should have a method like: MacroCategory getCategory() inside the Macro interface. Using this information MacroManager will present different macro categories to the outside world.
We could make the categories static at first, but we'll quickly run into either of 2 issues: - someone wants to add a new macro and doesn't find a category that fits - there are too many macros in a given category Thus it would be better if we could make the list of macro categories configurable. * The other approach is to keep this categorization inside some wiki pages
and allow administrators to manipulate it: Create / Edit categories, assign macros to categories etc. I'm not sure what problems this would create when implementing macro browser though.
That's the approach I'd favor. Macro categories would be defined from the administration interface. The user who creates a new macro would select the category that fits best from that list of categories. Since right now an user has to have programming rights to create new macros and that programming rights have to be granted by an admin, we can expect that the user will be able to ask the admin for a new category should the need arise. That could be implemented through a static list in a XClass. We'd need to add a good-looking administration interface to define the list of categories. * Another (very hackish) approach would be to use the component role hint in
the same fashion it is used to specify macros for different syntaxes.
I think this is enough to get the discussion started.
Thank you very much for your input.
- Asiri
Guillaume _______________________________________________
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi, That's the approach I'd favor. Macro categories would be defined from the
administration interface. The user who creates a new macro would select the category that fits best from that list of categories.
Sounds good for wiki macros. But what about java macros? Should they have a String getCategory() / setCategory(String) like thing? If so MacroManager needs to store macros by category as well.. (I'm just thinking out loud) - Asiri
* Presentation - Macros that allow presenting document content with various styles. Like box & code macros
* Document content - Macros that add stuff into a wiki page, like image, video & office macros.
I think box macro is a notification. Code macro needs to be in the Development category and not Presentation. When you say presentation I'm thinking about images, colors, etc.
On Aug 3, 2009, at 5:58 PM, Ecaterina Valica wrote:
* Presentation - Macros that allow presenting document content with various styles. Like box & code macros
* Document content - Macros that add stuff into a wiki page, like image, video & office macros.
I think box macro is a notification. Code macro needs to be in the Development category and not Presentation.
I'm not sure... Code macro is presentation and not development IMO. For me development = people who want to do development = macros for developers Code macro is about pretty printing code snippets found elsewhere.
When you say presentation I'm thinking about images, colors, etc.
Yep this is what the code macro is about ;) Thanks -Vincent
Vincent Massol wrote:
On Aug 3, 2009, at 5:58 PM, Ecaterina Valica wrote:
* Presentation - Macros that allow presenting document content with various styles. Like box & code macros
* Document content - Macros that add stuff into a wiki page, like image, video & office macros.
I think box macro is a notification. Code macro needs to be in the Development category and not Presentation.
I'm not sure...
Code macro is presentation and not development IMO. For me development = people who want to do development = macros for developers
Code macro is about pretty printing code snippets found elsewhere.
When you say presentation I'm thinking about images, colors, etc.
Yep this is what the code macro is about ;)
+1 -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Aug 3, 2009, at 5:08 PM, Asiri Rathnayake wrote:
I think this is enough to get the discussion started.
Thank you very much for your input.
Eclipse does this in the following way: 1) Every plugin is free to add new categories. A category is defined by an id, a name and a parent. 2) Every view could declare to be in a given category (by using the corresponding id) The structure subsumed by 1 and 2 is reflected in the menu dialog box that opens up when you choose Window->Show view->Other from the Eclipse IDE If a plugin doesn't declare a category it is put in the "Other" category (which exists by default) If a plugin declares a category id that doesn't exist, it is put in the "Other" category as well. While the "every plugin could declare to be in a given category" is easily casted to the Macro world, I am not sure how to translate the "every plugin is free to add new categories". -Fabio
While the "every plugin could declare to be in a given category" is easily casted to the Macro world, I am not sure how to translate the "every plugin is free to add new categories".
How about like this: * Each macro has a getCategory() method. * Macro manager calls this method and if the category is an existing one, it is put into that collection. * If that category is new, a new category (collection) is created and the macro put inside it. * Clients will call methods like getCategories() getMacrosForCategory() on MacroManager(). But things are little complex with macros for various syntaxes and all. Just a thought. - Asiri
-Fabio _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
While the "every plugin could declare to be in a given category" is easily casted to the Macro world, I am not sure how to translate the "every plugin is free to add new categories".
How about like this:
* Each macro has a getCategory() method.
* Macro manager calls this method and if the category is an existing one, it is put into that collection.
The problem with this is that a "category" is a data structure so test for equality could be problematic. Imagine 3 macros return: ID:category1 Name:Foo foo foo Icon:foo.jpg ID:category1 Name:Bar bar bar Icon:bar.jpg ID:category2 name:Foo foo foo Icon:baz.jpg How would you handle this? Imho, getCategory() should return a simple string that is an id of a category defined and stored in a "registry" The problem is how could a macro put a category inside this registry? Maybe at initialization time it could do store new categories in the registry (if it wants to do so) so that a subsequent call to getCategory would return an existing id. The registry could also be populated by default with a set of "standard" categories (maybe defined in some wiki pages). -Fabio
Hi On Mon, Aug 3, 2009 at 10:31 PM, Fabio Mancinelli < fabio.mancinelli@xwiki.com> wrote:
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
While the "every plugin could declare to be in a given category" is easily casted to the Macro world, I am not sure how to translate the "every plugin is free to add new categories".
How about like this:
* Each macro has a getCategory() method.
* Macro manager calls this method and if the category is an existing one, it is put into that collection.
The problem with this is that a "category" is a data structure so test for equality could be problematic.
Imagine 3 macros return:
ID:category1 Name:Foo foo foo Icon:foo.jpg
ID:category1 Name:Bar bar bar Icon:bar.jpg
ID:category2 name:Foo foo foo Icon:baz.jpg
How would you handle this?
My idea was to make a "category" not a data structure but a simple string only, I don't think there is a requirement for categories to be data structures at this moment (IMHO). As vincent suggested, getCategory() method of MacroDescriptor could: 1. Check if "org.xwiki.macro.<macro_name>.category" configuration option is set in xwiki.properties 2. If it is set, return that value. 3. Otherwise, return a default value This would allow editing macro categories and arranging macros into categories as admins prefer. I wonder what Guillaume thinks about this :) Few issues with this approach arises with MacroManager::getCategories() & MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system. - Asiri
Imho, getCategory() should return a simple string that is an id of a category defined and stored in a "registry" The problem is how could a macro put a category inside this registry?
Maybe at initialization time it could do store new categories in the registry (if it wants to do so) so that a subsequent call to getCategory would return an existing id.
The registry could also be populated by default with a set of "standard" categories (maybe defined in some wiki pages).
-Fabio _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Aug 4, 2009, at 5:42 AM, Asiri Rathnayake wrote:
Hi
On Mon, Aug 3, 2009 at 10:31 PM, Fabio Mancinelli < fabio.mancinelli@xwiki.com> wrote:
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
While the "every plugin could declare to be in a given category" is easily casted to the Macro world, I am not sure how to translate the "every plugin is free to add new categories".
How about like this:
* Each macro has a getCategory() method.
* Macro manager calls this method and if the category is an existing one, it is put into that collection.
The problem with this is that a "category" is a data structure so test for equality could be problematic.
Imagine 3 macros return:
ID:category1 Name:Foo foo foo Icon:foo.jpg
ID:category1 Name:Bar bar bar Icon:bar.jpg
ID:category2 name:Foo foo foo Icon:baz.jpg
How would you handle this?
My idea was to make a "category" not a data structure but a simple string only, I don't think there is a requirement for categories to be data structures at this moment (IMHO).
As vincent suggested, getCategory() method of MacroDescriptor could:
1. Check if "org.xwiki.macro.<macro_name>.category" configuration option is set in xwiki.properties
2. If it is set, return that value.
3. Otherwise, return a default value
This would allow editing macro categories and arranging macros into categories as admins prefer. I wonder what Guillaume thinks about this :)
Few issues with this approach arises with MacroManager::getCategories() & MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system.
This is not really a problem. 2 solutions: 1) cm.lookupList() is immediate and you just need to loop. 2) you can subscribe to Component Manager registrations events and refresh a category cache when a new macro is registered/unregistered -Vincent
- Asiri
Imho, getCategory() should return a simple string that is an id of a category defined and stored in a "registry" The problem is how could a macro put a category inside this registry?
Maybe at initialization time it could do store new categories in the registry (if it wants to do so) so that a subsequent call to getCategory would return an existing id.
The registry could also be populated by default with a set of "standard" categories (maybe defined in some wiki pages).
-Fabio
On Tue, Aug 4, 2009 at 05:42, Asiri Rathnayake<asiri.rathnayake@gmail.com> wrote:
Hi
On Mon, Aug 3, 2009 at 10:31 PM, Fabio Mancinelli < fabio.mancinelli@xwiki.com> wrote:
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
While the "every plugin could declare to be in a given category" is easily casted to the Macro world, I am not sure how to translate the "every plugin is free to add new categories".
How about like this:
* Each macro has a getCategory() method.
* Macro manager calls this method and if the category is an existing one, it is put into that collection.
The problem with this is that a "category" is a data structure so test for equality could be problematic.
Imagine 3 macros return:
ID:category1 Name:Foo foo foo Icon:foo.jpg
ID:category1 Name:Bar bar bar Icon:bar.jpg
ID:category2 name:Foo foo foo Icon:baz.jpg
How would you handle this?
My idea was to make a "category" not a data structure but a simple string only, I don't think there is a requirement for categories to be data structures at this moment (IMHO).
As vincent suggested, getCategory() method of MacroDescriptor could:
1. Check if "org.xwiki.macro.<macro_name>.category" configuration option is set in xwiki.properties
2. If it is set, return that value.
3. Otherwise, return a default value
This would allow editing macro categories and arranging macros into categories as admins prefer. I wonder what Guillaume thinks about this :)
Few issues with this approach arises with MacroManager::getCategories() & MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system.
+1 for this as a first implementation and no it's not a problem, it's just mean loop the macros and compare the category string with the provided String, it does not cost much in JAVA.
- Asiri
Imho, getCategory() should return a simple string that is an id of a category defined and stored in a "registry" The problem is how could a macro put a category inside this registry?
Maybe at initialization time it could do store new categories in the registry (if it wants to do so) so that a subsequent call to getCategory would return an existing id.
The registry could also be populated by default with a set of "standard" categories (maybe defined in some wiki pages).
-Fabio _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, On Tue, Aug 4, 2009 at 9:56 AM, Thomas Mortagne <thomas.mortagne@xwiki.com>wrote:
On Tue, Aug 4, 2009 at 05:42, Asiri Rathnayake<asiri.rathnayake@gmail.com> wrote:
Hi
On Mon, Aug 3, 2009 at 10:31 PM, Fabio Mancinelli < fabio.mancinelli@xwiki.com> wrote:
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
While the "every plugin could declare to be in a given category" is easily casted to the Macro world, I am not sure how to translate the "every plugin is free to add new categories".
How about like this:
* Each macro has a getCategory() method.
* Macro manager calls this method and if the category is an existing one, it is put into that collection.
The problem with this is that a "category" is a data structure so test for equality could be problematic.
Imagine 3 macros return:
ID:category1 Name:Foo foo foo Icon:foo.jpg
ID:category1 Name:Bar bar bar Icon:bar.jpg
ID:category2 name:Foo foo foo Icon:baz.jpg
How would you handle this?
My idea was to make a "category" not a data structure but a simple string only, I don't think there is a requirement for categories to be data structures at this moment (IMHO).
As vincent suggested, getCategory() method of MacroDescriptor could:
1. Check if "org.xwiki.macro.<macro_name>.category" configuration option is set in xwiki.properties
2. If it is set, return that value.
3. Otherwise, return a default value
This would allow editing macro categories and arranging macros into categories as admins prefer. I wonder what Guillaume thinks about this :)
For a first implementation I think we should avoid trying to do too much. A simple list of categories defined by the wiki admin + an "Others" category for macros that don't have a category assigned to them is enough to get started with. The macro creator chooses which category to use from the list of available categories on the wiki when creating his new one.
From what I understand it can be done in an acceptable fashion on the technical side.
Another thing we need to decide is whether we want the category to be a multiselect -> can a macro declare itself in 2 categories? For a start I'd favor us using a simple select (a macro can only be in one category), WDYT? Having multiple categories for macros doesn't bring that much value and it's not really needed in the short term. Guillaume
Few issues with this approach arises with MacroManager::getCategories() &
MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system.
+1 for this as a first implementation and no it's not a problem, it's just mean loop the macros and compare the category string with the provided String, it does not cost much in JAVA.
- Asiri
Imho, getCategory() should return a simple string that is an id of a category defined and stored in a "registry" The problem is how could a macro put a category inside this registry?
Maybe at initialization time it could do store new categories in the registry (if it wants to do so) so that a subsequent call to getCategory would return an existing id.
The registry could also be populated by default with a set of "standard" categories (maybe defined in some wiki pages).
-Fabio _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi,
This would allow editing macro categories and arranging macros into
categories as admins prefer. I wonder what Guillaume thinks about this :)
For a first implementation I think we should avoid trying to do too much. A simple list of categories defined by the wiki admin + an "Others" category for macros that don't have a category assigned to them is enough to get started with. The macro creator chooses which category to use from the list of available categories on the wiki when creating his new one.
From what I understand it can be done in an acceptable fashion on the technical side.
Another thing we need to decide is whether we want the category to be a multiselect -> can a macro declare itself in 2 categories? For a start I'd favor us using a simple select (a macro can only be in one category), WDYT?
+1 I think for the moment this is ok. Question: For wiki macros are we going to provide string property where the user can enter the category in object edit mode? To make this a select (combo box) we would need an wiki macro authoring application(?). But for the moment I think a single string property would do. WDYT? Thanks. - Asiri
Having multiple categories for macros doesn't bring that much value and it's not really needed in the short term.
Guillaume
Few issues with this approach arises with MacroManager::getCategories() &
MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system.
+1 for this as a first implementation and no it's not a problem, it's just mean loop the macros and compare the category string with the provided String, it does not cost much in JAVA.
- Asiri
Imho, getCategory() should return a simple string that is an id of a category defined and stored in a "registry" The problem is how could a macro put a category inside this registry?
Maybe at initialization time it could do store new categories in the registry (if it wants to do so) so that a subsequent call to getCategory would return an existing id.
The registry could also be populated by default with a set of "standard" categories (maybe defined in some wiki pages).
-Fabio _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Aug 4, 2009 at 11:10 AM, Asiri Rathnayake < asiri.rathnayake@gmail.com> wrote:
Hi,
This would allow editing macro categories and arranging macros into
categories as admins prefer. I wonder what Guillaume thinks about this :)
For a first implementation I think we should avoid trying to do too much. A simple list of categories defined by the wiki admin + an "Others" category for macros that don't have a category assigned to them is enough to get started with. The macro creator chooses which category to use from the list of available categories on the wiki when creating his new one.
From what I understand it can be done in an acceptable fashion on the technical side.
Another thing we need to decide is whether we want the category to be a multiselect -> can a macro declare itself in 2 categories? For a start I'd favor us using a simple select (a macro can only be in one category), WDYT?
+1 I think for the moment this is ok.
Question:
For wiki macros are we going to provide string property where the user can enter the category in object edit mode? To make this a select (combo box) we would need an wiki macro authoring application(?). But for the moment I think a single string property would do. WDYT?
Why wouldn't you be able to have a combo box in an object? All you need to do is to store the list of categories in a StaticList in the XClass that defines macro XObjects and the combo box will be generated automatically in Object edition mode (or maybe I'm missing something?) Guillaume Thanks.
- Asiri
Having multiple categories for macros doesn't bring that much value and it's not really needed in the short term.
Guillaume
Few issues with this approach arises with MacroManager::getCategories()
&
MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system.
+1 for this as a first implementation and no it's not a problem, it's just mean loop the macros and compare the category string with the provided String, it does not cost much in JAVA.
- Asiri
Imho, getCategory() should return a simple string that is an id of a category defined and stored in a "registry" The problem is how could a macro put a category inside this
registry?
Maybe at initialization time it could do store new categories in the registry (if it wants to do so) so that a subsequent call to getCategory would return an existing id.
The registry could also be populated by default with a set of "standard" categories (maybe defined in some wiki pages).
-Fabio _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi,
Question:
For wiki macros are we going to provide string property where the user can enter the category in object edit mode? To make this a select (combo box) we would need an wiki macro authoring application(?). But for the moment I think a single string property would do. WDYT?
Why wouldn't you be able to have a combo box in an object? All you need to do is to store the list of categories in a StaticList in the XClass that defines macro XObjects and the combo box will be generated automatically in Object edition mode (or maybe I'm missing something?)
Since macros can define new categories (via getCategory() method) and since they can be overwritten in xwiki.properties file, we do not know what exact macro categories are there in the system. Also, a wiki macro should be able to define it's own category as well. So a static list will not suffice here IMHO. Thanks. - Asiri
Guillaume
Thanks.
- Asiri
Having multiple categories for macros doesn't bring that much value and it's not really needed in the short term.
Guillaume
Few issues with this approach arises with
MacroManager::getCategories()
&
MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system.
+1 for this as a first implementation and no it's not a problem, it's just mean loop the macros and compare the category string with the provided String, it does not cost much in JAVA.
- Asiri
Imho, getCategory() should return a simple string that is an id of
a
category defined and stored in a "registry" The problem is how could a macro put a category inside this registry?
Maybe at initialization time it could do store new categories in the registry (if it wants to do so) so that a subsequent call to getCategory would return an existing id.
The registry could also be populated by default with a set of "standard" categories (maybe defined in some wiki pages).
-Fabio _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Aug 4, 2009 at 11:29 AM, Asiri Rathnayake < asiri.rathnayake@gmail.com> wrote:
Hi,
Question:
For wiki macros are we going to provide string property where the user can enter the category in object edit mode? To make this a select (combo
box)
we would need an wiki macro authoring application(?). But for the moment I think a single string property would do. WDYT?
Why wouldn't you be able to have a combo box in an object? All you need to do is to store the list of categories in a StaticList in the XClass that defines macro XObjects and the combo box will be generated automatically in Object edition mode (or maybe I'm missing something?)
Since macros can define new categories (via getCategory() method) and since they can be overwritten in xwiki.properties file, we do not know what exact macro categories are there in the system. Also, a wiki macro should be able to define it's own category as well. So a static list will not suffice here IMHO.
Do we really need / want macros to be able to define their own categories at first? It means we might end up with "category clutter" in the macro browser, specifically if the user who creates the macro has to go find the list of currently existing categories in a configuration file -> the lazy option will simply be to make a category name up and we'll end up with "display", "Display", "Look" & "Appearance" as categories and the user won't really know where the macro he's looking for is located. My point of view is that the wiki admin should be able to define a fixed set of available categories and the macro creator has to select a category out of the predefined list ones when adding a new macro. Letting each macro define its own category is overkill, at least for a start. I can already hear our project managers asking how they can restrict the list of categories and I don't want to have to tell them that they can't :-) Guillaume Thanks.
- Asiri
Guillaume
Thanks.
- Asiri
Having multiple categories for macros doesn't bring that much value
and
it's not really needed in the short term.
Guillaume
Few issues with this approach arises with MacroManager::getCategories() &
MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system.
+1 for this as a first implementation and no it's not a problem, it's just mean loop the macros and compare the category string with the provided String, it does not cost much in JAVA.
- Asiri
> Imho, getCategory() should return a simple string that is an id
of a
> category defined and stored in a "registry" > The problem is how could a macro put a category inside this registry? > > Maybe at initialization time it could do store new categories in the > registry (if it wants to do so) so that a subsequent call to > getCategory would return an existing id. > > The registry could also be populated by default with a set of > "standard" categories (maybe defined in some wiki pages). > > -Fabio > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On Tue, Aug 4, 2009 at 11:44, Guillaume Lerouge<guillaume@xwiki.com> wrote:
Hi,
On Tue, Aug 4, 2009 at 11:29 AM, Asiri Rathnayake < asiri.rathnayake@gmail.com> wrote:
Hi,
Question:
For wiki macros are we going to provide string property where the user can enter the category in object edit mode? To make this a select (combo
box)
we would need an wiki macro authoring application(?). But for the moment I think a single string property would do. WDYT?
Why wouldn't you be able to have a combo box in an object? All you need to do is to store the list of categories in a StaticList in the XClass that defines macro XObjects and the combo box will be generated automatically in Object edition mode (or maybe I'm missing something?)
Since macros can define new categories (via getCategory() method) and since they can be overwritten in xwiki.properties file, we do not know what exact macro categories are there in the system. Also, a wiki macro should be able to define it's own category as well. So a static list will not suffice here IMHO.
Do we really need / want macros to be able to define their own categories at first? It means we might end up with "category clutter" in the macro browser, specifically if the user who creates the macro has to go find the list of currently existing categories in a configuration file -> the lazy option will simply be to make a category name up and we'll end up with "display", "Display", "Look" & "Appearance" as categories and the user won't really know where the macro he's looking for is located.
My point of view is that the wiki admin should be able to define a fixed set of available categories and the macro creator has to select a category out of the predefined list ones when adding a new macro.
Letting each macro define its own category is overkill, at least for a start. I can already hear our project managers asking how they can restrict the list of categories and I don't want to have to tell them that they can't :-)
Guillaume the last proposal of Asiri and for which I agree was to consider category defined by the macro author as a default category and let the admin the possibility to overwrite it. Technically the getCategory is 10 minutes of work the bigger work is to do the admin UI you want... Force people to configure category to have access to the macro is a pain, we just need to allow them to set it if they don't like what the author chose. There is no debate on getCategory against admin listed category IMO.
Guillaume
Thanks.
- Asiri
Guillaume
Thanks.
- Asiri
Having multiple categories for macros doesn't bring that much value
and
it's not really needed in the short term.
Guillaume
Few issues with this approach arises with MacroManager::getCategories() & > MacroManager::getMacrosForCategory() method implementations. Since we have > dynamic macro registrations (wiki macros), each of these methods will have > to build the response by going through all the macros in the system.
+1 for this as a first implementation and no it's not a problem, it's just mean loop the macros and compare the category string with the provided String, it does not cost much in JAVA.
> > - Asiri > > >> Imho, getCategory() should return a simple string that is an id of a >> category defined and stored in a "registry" >> The problem is how could a macro put a category inside this registry? >> >> Maybe at initialization time it could do store new categories in the >> registry (if it wants to do so) so that a subsequent call to >> getCategory would return an existing id. >> >> The registry could also be populated by default with a set of >> "standard" categories (maybe defined in some wiki pages). >> >> -Fabio >> _______________________________________________ >> devs mailing list >> devs@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, On Tue, Aug 4, 2009 at 11:55 AM, Thomas Mortagne <thomas.mortagne@xwiki.com>wrote:
On Tue, Aug 4, 2009 at 11:44, Guillaume Lerouge<guillaume@xwiki.com> wrote:
Hi,
On Tue, Aug 4, 2009 at 11:29 AM, Asiri Rathnayake < asiri.rathnayake@gmail.com> wrote:
Hi,
Question:
For wiki macros are we going to provide string property where the
user
can
enter the category in object edit mode? To make this a select (combo box) we would need an wiki macro authoring application(?). But for the moment I think a single string property would do. WDYT?
Why wouldn't you be able to have a combo box in an object? All you need to do is to store the list of categories in a StaticList in the XClass that defines macro XObjects and the combo box will be generated automatically in Object edition mode (or maybe I'm missing something?)
Since macros can define new categories (via getCategory() method) and since they can be overwritten in xwiki.properties file, we do not know what exact macro categories are there in the system. Also, a wiki macro should be able to define it's own category as well. So a static list will not suffice here IMHO.
Do we really need / want macros to be able to define their own categories at first? It means we might end up with "category clutter" in the macro browser, specifically if the user who creates the macro has to go find the list of currently existing categories in a configuration file -> the lazy option will simply be to make a category name up and we'll end up with "display", "Display", "Look" & "Appearance" as categories and the user won't really know where the macro he's looking for is located.
My point of view is that the wiki admin should be able to define a fixed set of available categories and the macro creator has to select a category out of the predefined list ones when adding a new macro.
Letting each macro define its own category is overkill, at least for a start. I can already hear our project managers asking how they can restrict the list of categories and I don't want to have to tell them that they can't :-)
Guillaume the last proposal of Asiri and for which I agree was to consider category defined by the macro author as a default category and let the admin the possibility to overwrite it. Technically the getCategory is 10 minutes of work the bigger work is to do the admin UI you want... Force people to configure category to have access to the macro is a pain, we just need to allow them to set it if they don't like what the author chose. There is no debate on getCategory against admin listed category IMO.
Ok, I get it now. Thanks for the explanation :-) Indeed, as long as admins can change the default category to another one at macro installation time it's fine. Guillaume
Guillaume
Thanks.
- Asiri
Guillaume
Thanks.
- Asiri
Having multiple categories for macros doesn't bring that much
value
and
it's not really needed in the short term.
Guillaume
> Few issues with this approach arises with MacroManager::getCategories() & > > MacroManager::getMacrosForCategory() method implementations. Since we > have > > dynamic macro registrations (wiki macros), each of these methods will > have > > to build the response by going through all the macros in the system. > > +1 for this as a first implementation and no it's not a problem, it's > just mean loop the macros and compare the category string with the > provided String, it does not cost much in JAVA. > > > > > - Asiri > > > > > >> Imho, getCategory() should return a simple string that is an id of a > >> category defined and stored in a "registry" > >> The problem is how could a macro put a category inside this registry? > >> > >> Maybe at initialization time it could do store new categories in the > >> registry (if it wants to do so) so that a subsequent call to > >> getCategory would return an existing id. > >> > >> The registry could also be populated by default with a set of > >> "standard" categories (maybe defined in some wiki pages). > >> > >> -Fabio > >> _______________________________________________ > >> devs mailing list > >> devs@xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > devs@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On Tue, Aug 4, 2009 at 11:29, Asiri Rathnayake<asiri.rathnayake@gmail.com> wrote:
Hi,
Question:
For wiki macros are we going to provide string property where the user can enter the category in object edit mode? To make this a select (combo box) we would need an wiki macro authoring application(?). But for the moment I think a single string property would do. WDYT?
Why wouldn't you be able to have a combo box in an object? All you need to do is to store the list of categories in a StaticList in the XClass that defines macro XObjects and the combo box will be generated automatically in Object edition mode (or maybe I'm missing something?)
Since macros can define new categories (via getCategory() method) and since they can be overwritten in xwiki.properties file, we do not know what exact macro categories are there in the system. Also, a wiki macro should be able to define it's own category as well. So a static list will not suffice here IMHO.
Put a String property in the object and we can provide later a UI to edit macro properties, in this case you can dynamically list anything you want to present to the user.
Thanks.
- Asiri
Guillaume
Thanks.
- Asiri
Having multiple categories for macros doesn't bring that much value and it's not really needed in the short term.
Guillaume
Few issues with this approach arises with
MacroManager::getCategories()
&
MacroManager::getMacrosForCategory() method implementations. Since we have dynamic macro registrations (wiki macros), each of these methods will have to build the response by going through all the macros in the system.
+1 for this as a first implementation and no it's not a problem, it's just mean loop the macros and compare the category string with the provided String, it does not cost much in JAVA.
- Asiri
> Imho, getCategory() should return a simple string that is an id of
a
> category defined and stored in a "registry" > The problem is how could a macro put a category inside this registry? > > Maybe at initialization time it could do store new categories in the > registry (if it wants to do so) so that a subsequent call to > getCategory would return an existing id. > > The registry could also be populated by default with a set of > "standard" categories (maybe defined in some wiki pages). > > -Fabio > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
While the "every plugin could declare to be in a given category" is easily casted to the Macro world, I am not sure how to translate the "every plugin is free to add new categories".
How about like this:
* Each macro has a getCategory() method.
I guess you mean Macro Descriptor and not Macro. [snip] Idea: Macro Descriptors could use a Configuration component to get the default category for the macro, thus overridable in xwiki's configuration mechanism (xwiki.properties, XWikiPreferences, etc). -Vincent
participants (7)
-
Asiri Rathnayake -
Ecaterina Valica -
Fabio Mancinelli -
Guillaume Lerouge -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol