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