16 Jul
2009
16 Jul
'09
11:02 a.m.
On Wed, Jul 15, 2009 at 21:41, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
Hi,
I don't think we should protect java macros from wiki macros. Someone
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.
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)
Thanks.
- Asiri
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne