On Wed, Jul 15, 2009 at 21:41, Asiri Rathnayake<[email protected]> wrote:
Hi,
I don't think we should protect java macros from wiki macros. Someone
with programming right is supposed to know enough to take care of what he's doing. It's even a feature for me to be able to customize any macro even the java ones from the wiki. If it's really needed you could have an option for protecting java macros but i really think it's not necessary.
There is a small problem with redefining java macros: the newly defined wiki macro will not be able to access the old java macro if it wants to act like a decorator for example. I mean If I define a wiki macro named "box" i will be overriding the original box macro and if I try to refer the original box macro within my newly defined wiki macro, I would create an infinite loop instead. We have to prohibit defining recursive wiki macros (wiki macro referring itself would create loops). Even though this could be overcome by using parameters appropriately, I think its too dangerous. WDYT?
(PS: I haven't tested a recursive wiki macro yet, can't wait to see what happens)
Protect from infinite look is MacroTransformation job, it does not have anything to do with wiki macros. When i said customize i was not thinking of decoration but a rewrite. Note that a macro written in groovy for example could still use directly java macro class even it's not very clean when the has some @Requirement but still possible. Most of the complex macros take care of being modular as much as possible with sub components or just classes so customize such a java maro and reusing sub component/class would no be very difficult. Anyway I still don't see reason to forbid overwrite java macros.
Thanks.
- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne