4 Aug
2009
4 Aug
'09
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