Re: [xwiki-devs] [Proposal] Add support for bridging Velocity Macros with the new Rendering

Hello, First, agreed with Thomas, we should make this generic and allow to define macros with all script languages we support. I started to give it a shot, I think this would really accelerate the number of syntax 2.0 macro we can distribute (both written by us or contributions). Below my findings / questions : 1. Initialization (creating the MacroClass if not present already) This is going to be very hard to do oustide xwiki-core. One thing is that their is no store available as long as the main XWiki object is not initialized, and some work is needed to make this happen without having to wait for the first HTTP request (and even if we do that, we have the problem with virtual wikis, for which we need to update the macro class too). An alternative would be to create a component interface for code that needs initialization once a wiki is initialized (wiki store, notification/observation manager, etc available) and lookup and call initialization method for all implementations once a wiki is ready. Even with this, we need bridges for adding class/class properties. I'm not sure we want that really, I think having the component implementation in the core too is a better option. 2. Querying documents that have a MacroClass object We don't have a bridge for that. My take is that we should have an interface like WikiMacroStore which default implementation would be in xwiki-core, and once we have the new model & storage we reimplement it in another place. The MacroManager would have this store as injected dependency. Maybe this implentation in core could be responsible to initialize the MacroClass too. 3. Observation This is possible to have as a component implementation outside core, but would mean having to add a version property to the DocumentModelBridge, and overload methods from the DocumentAccessBridge adding a version parameter, since we need to compare things (was there a MacroClass object deleted ? etc.). I'm not very conviced by this, since its more bridge code that will need to be changed later. Alternatives I see are either a component implementation in core (maybe that WikiStore too) that would subscribe to notifications, compare things upon notify, and generate custom events that the MacroManager listens to (like WikiMacroDeleted, WikiMacroChanged, etc.) It would mean the macro manager component defines its own set of events. Third possibility is that the macro store (or whatever thing we create to listens to analyze macro related notifications in core) call itself the macro manager to register/unregister macors. But I don't think it's right this way. So at the end, I see the MacroManager as a component thats knows how to register/unregister a "WikiScriptMacro" (in xwiki-rendering-macro-script, that extends the AbstractScriptMacro) implementation to/from the component manager. Upon initialization, it asks a WikiMacroStore to return all active macros in the wiki and register them. Then it listens to events from the observation manager to load/unload when a new macro is created, a macro is deleted or loses its programming right, etc. As for where should it go, I think the rendering module is the best option, tell me if I'm wrong. (At least not xwiki-velocity if it supports several languages). I did not started to look at parameters handling yet. In advance, thanks for your feedback Jerome. PS: I created a JIRA issue for it: http://jira.xwiki.org/jira/browse/XWIKI-3213 Thomas Mortagne wrote: