6 Aug
2009
6 Aug
'09
1:38 p.m.
Hi,
Yes, I agree with you. But I wondered, if a user is writing a java macro, he
knows java!
But again a constructor like
* public AbstractMacro(MacroDescriptor);
Would make his life bit worse and doing something like:
super(new DefaultMacroDescriptor(... new DefaultContentDescriptor())) is
ugly.
The other problem is He has to know about BeanManager and component
injection with this sort of a constructor..
So yes, it makes his life hard.
Still, I'm a bit uncomfortable with the fact that introducing a new
attribute to MacroDescriptor and being unable to expose it to the macro
author in a simple way.
Anyway, I'm halfway down the implementation so, it's better if things do not
change now ;)
- Asiri
My question
is, why do we have to make AbstractMacro constructors so
simple?
Because we want to make as easy as possible to write and contribute macros
:)
Can't we
have these two constructors only?
* public AbstractMacro();
* public AbstractMacro(MacroDescriptor);
The problem with this approach is that a client will have to do little
more
work like;
ContentDescriptor myContentDescriptor = new
DefaultContentDescriptor("This
is my content", true);
MacroDescriptor myMacroDescriptor = new DefaultMacroDescriptor("This is
my
macro", myContentDescriptor,
beanManager.getBeanDescriptor(MyParametersClass.Class))
super(myMacroDescriptor);
Even though this is too much of work, I think it will make the API more
extensible an clean.
This is only my opinion. I didn't want to drag this issue this far but I
just couldn't feel myself comfortable with the way I'm going to implement
the macro categories support.
Up to you.
Thanks.
- Asiri
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs