On Feb 10, 2009, at 12:35 AM, Jerome Velociter wrote: > Another thing, I can't see yet a clean way of having per-instance > macros > on wiki farms. In virtual mode all wikis are going to share the same > macros, which can be both annoying (macro list in WYSIWYG can appear > polluted) and dangerous (Admin A. on wiki A overrides macro B. from > Admin B. on wiki B without A. being noticed).
You could have one wiki macro manager per wiki. It looks for all macro objects in a given database. -Vincent > Jerome. > > 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. >> >> 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
