3 Aug
2009
3 Aug
'09
5:08 p.m.
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
3 Aug
3 Aug
5:56 p.m.
Hi Asiri,
On Mon, Aug 3, 2009 at 5:08 PM, Asiri Rathnayake <asiri.rathnayake(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
6:19 p.m.
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
5:58 p.m.
* 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.
7:04 p.m.
On Aug 3, 2009, at 5:58 PM, Ecaterina Valica wrote:
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.
* 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.
Yep this is what the code macro is about ;)
Thanks
-Vincent
6 Aug
6 Aug
3:25 a.m.
Vincent Massol wrote:
On Aug 3, 2009, at 5:58 PM, Ecaterina Valica wrote:
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.
+1
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
*
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.
Yep this is what the code macro is about ;) 
3 Aug
3 Aug
6:19 p.m.
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
6:27 p.m.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:01 p.m.
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
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
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.
4 Aug
4 Aug
5:42 a.m.
Hi
On Mon, Aug 3, 2009 at 10:31 PM, Fabio Mancinelli <
fabio.mancinelli(a)xwiki.com> wrote:
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
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
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.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:01 a.m.
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(a)xwiki.com> wrote:
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
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
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. 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.
- 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
9:56 a.m.
On Tue, Aug 4, 2009 at 05:42, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
Hi
On Mon, Aug 3, 2009 at 10:31 PM, Fabio Mancinelli <
fabio.mancinelli(a)xwiki.com> wrote:
+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.
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
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. 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.
- Asiri
--
Thomas Mortagne
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:59 a.m.
Hi,
On Tue, Aug 4, 2009 at 9:56 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Tue, Aug 4, 2009 at 05:42, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
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.
Hi
On Mon, Aug 3, 2009 at 10:31 PM, Fabio Mancinelli <
fabio.mancinelli(a)xwiki.com> wrote:
is
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
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
> 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?
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 :)
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() &
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:10 a.m.
Hi,
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
This would
allow editing macro categories and arranging macros into
> categories as admins prefer. I wonder what Guillaume thinks about this
:)
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() &
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:15 a.m.
Hi,
On Tue, Aug 4, 2009 at 11:10 AM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
Hi,
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.
> 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?
- Asiri
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
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(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
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
11:29 a.m.
Hi,
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
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.
the
_______________________________________________
devs mailing list
devs(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
- 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
>> 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(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> 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
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:44 a.m.
Hi,
On Tue, Aug 4, 2009 at 11:29 AM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
Hi,
box)
to
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.
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 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 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.
- Asiri
Since
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
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. we
it's
> > 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,
> > > 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
the
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>
>> 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
>
>> 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(a)xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > _______________________________________________
> > 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
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:55 a.m.
On Tue, Aug 4, 2009 at 11:44, Guillaume Lerouge<guillaume(a)xwiki.com> wrote:
Hi,
On Tue, Aug 4, 2009 at 11:29 AM, Asiri Rathnayake <
asiri.rathnayake(a)gmail.com> wrote:
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.
Hi,
box)
to
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
:-) 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 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 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.
Guillaume
Thanks.
--
Thomas Mortagne
- Asiri
Since
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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. we
it's
> > 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,
> > > 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> > >> 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(a)xwiki.org
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > >>
> > > _______________________________________________
> > > 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
> >
>
>
>
> --
> Guillaume Lerouge
> Product Manager - XWiki
> Skype: wikibc
> Twitter: glerouge
> http://guillaumelerouge.com/
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:07 p.m.
Hi,
On Tue, Aug 4, 2009 at 11:55 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
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
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
On Tue, Aug 4, 2009 at 11:44, Guillaume
Lerouge<guillaume(a)xwiki.com>
wrote:
at
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
Hi,
On Tue, Aug 4, 2009 at 11:29 AM, Asiri Rathnayake <
asiri.rathnayake(a)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 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(a)xwiki.org
> > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > >>
> > > > _______________________________________________
> > > > 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
> > >
> >
> >
> >
> > --
> > Guillaume Lerouge
> > Product Manager - XWiki
> > Skype: wikibc
> > Twitter: glerouge
> > http://guillaumelerouge.com/
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:47 a.m.
On Tue, Aug 4, 2009 at 11:29, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
Hi,
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.
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?)
Thanks.
- Asiri
--
Thomas Mortagne
Guillaume
Thanks.
the
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
- 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
>
>> 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(a)xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > _______________________________________________
> > 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
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3 Aug
3 Aug
7:10 p.m.
On Aug 3, 2009, at 6:27 PM, Asiri Rathnayake wrote:
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
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.
5523
days inactive
5526
days old
20 comments
7 participants
participants (7)
-
Asiri Rathnayake -
Ecaterina Valica -
Fabio Mancinelli -
Guillaume Lerouge -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol