Jerome Velociter wrote: > 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.
Maybe in the end all initialization/class/versions of object manipulations best place would be in a old-fashioned plugin until we have the new model. There we have hooks for initalization, virtual initialization, objects APIs, etc. Just a thought... Jerome. > > 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: >> +1 for the general principal of using rendering api from script in >> place of velocity macros. >> >> I would prefer a MacroClass which can support any script language. >> Thanks to jsr223, the only difference with what you described is that >> the macro content would be executed with a different engine depending >> on a "language" field of the MacroClass (and the name of the class >> would be different ;)). This field would be to "velocity" by default I >> guess. >> >> On Wed, Feb 4, 2009 at 8:41 AM, Vincent Massol <[email protected]> wrote: >>> Hi, >>> >>> We need to allow users to write macros using Velocity and still use >>> the same mechanism as the new rendering. Basically this means >>> transforming velocity macros into Rendering Macros. Once this is done >>> then the velocity macro will be able to be used as standard Rendering >>> Macros, they'll appear in the new WYSIWYG, etc. >>> >>> Here's a proposal for doing so: >>> >>> * Split xwiki-velocity/ module into 2 >>> - xwiki-velocity-engine/ (the one currently in xwiki-velocity) >>> - xwiki-velocity-macro/ (the new one) >>> * In xwiki-velocity-macro create a VelocityMacroManager class that >>> does the following: >>> - initialize itself at xwiki startup >>> - create a VelocityMacroClass definition in the wiki if it doesn't >>> exist >>> - query the wiki for all objects of type VelocityMacroClass >>> - for each of them register them dynamically (we can already do >>> this) as a Rendering Macro >>> * The VelocityMacroClass has several fields: >>> - macro name, parameter names, parameters description, macro >>> description, usage example, velocity content to execute (the macro >>> content) >>> * The VelocityMacroManager register itself against the Observation >>> component to receive notifications whenever a VelocityMacroClass is >>> modified (added, removed, etc) >>> * Users will then be able to add velocity macros by simply creating a >>> new page, adding the VelocityMacroClass in it, fill the values. >>> * We should also provide a VelocityMacroClassSheet so that the macro >>> page containing the VelocityMacroClass can display the help for the >>> macro (self-standing) >>> >>> The nice thing is that this keeps velocity macro handling in the xwiki- >>> velocity/ module and makes it completely optional (i.e. the wiki will >>> still work and there's no ties with this feature elsewhere). >>> >>> WDYT? >>> >>> Thanks >>> -Vincent >>> http://xwiki.com >>> http://xwiki.org >>> http://massol.net >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
