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