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