[xwiki-devs] [DISCUSSION] Few Wiki - Macro - Bridge Design Decisions
Hi All, I have completed the wiki macro bridge implementation and it's almost ready to be comitted. However there were few design decisions taken that needs to be discussed / debated a little here. 1. wiki macro Initialization on startup This is about searching for existing wiki macro definition documents on XE startup and registering them as macros. As you might already know I cannot use the ApplicationStartupEvent for this purpose because at that time the XWikiContext is not available. This is true for any module that requires database access on XE startup. Currently this is not possible. The real solution for this is the new model which will be ready on XE startup. But until we have the new model there has to be a workaround for it. We found two solutions: - Initialize the XWiki on XE startup: Thomas says that this can be done by implementing ApplicationContextListener and making few changes to XWiki.initXWiki() method. - Have a WikiMacroInitializer component which will be invoked at the end of XWiki.initXWiki() method, like below: <code> // Initialize all wiki macros try { WikiMacroInitializer wikiMacroInitializer = Utils.getComponentManager().lookup(WikiMacroInitializer.class); wikiMacroInitializer.init(); } catch (ComponentLookupException ex) { LOG.error("Error while initializing wiki macros", ex); } </code> I went with the second approach because: It works, easy to implement, and we have 2.0M2 due today or tomorrow. The approach thomas suggested sounds much better than the approach I've taken but we don't know what problems it might pose and I don't know whether I have enough time to implement it. May be we can have it for 2.0M3. 2. wiki macros and virtual wikis There is a problem with supporting wiki macros comming from multiple wikis in a wiki farm. If a particular wiki is initialized at some point in time, it could introduce a bunch of new macros all of a sudden and it might also override some existing macros. For this reason we have restricted wiki macros only for the main wiki, if you need to create a wiki macro it has to be on the main wiki and you have to save it with programming rights. Note however that this doesn't solve the overriding issue, an admin could easily override an existing macro by defining a wiki macro with the same name, we do not have any protection for this yet. Should we do something about it? 3. wiki macro parameter binding It would be nice to define a wiki macro parameter named "param1" and refer to it inside a script as $param1. We can do this easily but this allows wiki macro authors to override default parameters like $xwiki, $context etc. So the approach we took is to bind the parameters through the XWikiContext. For an example, to refer macro parameters a wiki macro author will have to say: $context.macro.params.param1 -To acces macro content (body): $context.macro.content To access MacroTransformationContext: $context.macro.context So these are the design decisions we took during the development of the wiki macro bridge. Please let us know what you think. We might not be able to implement any big changes for 2.0M2 but we will be able to do it for 2.0M3, otherwise we will have to delay wiki macro bridge till 2.0M3 ;( Thanks. - Asiri
On Tue, Jul 14, 2009 at 06:38, Asiri Rathnayake<[email protected]> wrote:
Hi All,
I have completed the wiki macro bridge implementation and it's almost ready to be comitted. However there were few design decisions taken that needs to be discussed / debated a little here.
1. wiki macro Initialization on startup
This is about searching for existing wiki macro definition documents on XE startup and registering them as macros. As you might already know I cannot use the ApplicationStartupEvent for this purpose because at that time the XWikiContext is not available. This is true for any module that requires database access on XE startup. Currently this is not possible. The real solution for this is the new model which will be ready on XE startup. But until we have the new model there has to be a workaround for it. We found two solutions:
- Initialize the XWiki on XE startup: Thomas says that this can be done by implementing ApplicationContextListener and making few changes to XWiki.initXWiki() method.
- Have a WikiMacroInitializer component which will be invoked at the end of XWiki.initXWiki() method, like below:
<code> // Initialize all wiki macros try { WikiMacroInitializer wikiMacroInitializer = Utils.getComponentManager().lookup(WikiMacroInitializer.class); wikiMacroInitializer.init(); } catch (ComponentLookupException ex) { LOG.error("Error while initializing wiki macros", ex); } </code>
I went with the second approach because: It works, easy to implement, and we have 2.0M2 due today or tomorrow. The approach thomas suggested sounds much better than the approach I've taken but we don't know what problems it might pose and I don't know whether I have enough time to implement it. May be we can have it for 2.0M3.
2. wiki macros and virtual wikis
There is a problem with supporting wiki macros comming from multiple wikis in a wiki farm. If a particular wiki is initialized at some point in time, it could introduce a bunch of new macros all of a sudden and it might also override some existing macros. For this reason we have restricted wiki macros only for the main wiki, if you need to create a wiki macro it has to be on the main wiki and you have to save it with programming rights. Note however that this doesn't solve the overriding issue, an admin could easily override an existing macro by defining a wiki macro with the same name, we do not have any protection for this yet. Should we do something about it?
Note that this is temporary decision waiting for component realm implementation needed for the coming application manager. With component realms it will be possible to associate component (an so wiki macros) to a particular context like the wiki "wikiname", a space, a particular user, etc. Let's say the programming and main wiki choice is the safe temporary choice and i think it's ok to start. 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.
3. wiki macro parameter binding
It would be nice to define a wiki macro parameter named "param1" and refer to it inside a script as $param1. We can do this easily but this allows wiki macro authors to override default parameters like $xwiki, $context etc. So the approach we took is to bind the parameters through the XWikiContext.
For an example, to refer macro parameters a wiki macro author will have to say:
$context.macro.params.param1
-To acces macro content (body):
$context.macro.content
To access MacroTransformationContext:
$context.macro.context
Note that putting a secure unmodifiable macro object in $context is here to make sure no information is lost. It's still possible to put variable as direct binding or not easily with ScriptConetxtInitializer but we can decide this latter. The important thing for now IMO is to make sure the macro will have access to the input whatever the use case and parameters names.
So these are the design decisions we took during the development of the wiki macro bridge. Please let us know what you think. We might not be able to implement any big changes for 2.0M2 but we will be able to do it for 2.0M3, otherwise we will have to delay wiki macro bridge till 2.0M3 ;(
Thanks.
- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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) Thanks. - Asiri
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
participants (2)
-
Asiri Rathnayake -
Thomas Mortagne