Vincent Massol wrote: > 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.
Yes, the main (xwiki) wiki by default. Looks the best compromise. Jerome > > -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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
