Hi,
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 :)
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs