[xwiki-devs] [Proposal] Add support for bridging Velocity Macros with the new Rendering
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
Hi, Sounds good. I like the idea of XWiki object to define and describe macros. This will allow to declare parameters being mandatory or not, too. Jerome. Vincent Massol 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Feb 9, 2009 at 20:53, Jerome Velociter <jerome@xwiki.com> wrote:
Hello,
First, agreed with Thomas, we should make this generic and allow to define macros with all script languages we support.
Actually I think we should even support wiki content as macro content, you can always execute script if needed using {{velocity}}, {{groovy}} but it's more generic, more consistent with "all is wiki", it makes the code behind the scene much more simple since it will just render the macro content with macro parameters in the context and anyway we need to indicate the content syntaxid to be able to parser the result of execution. If we really need a way to have just script in content we could always have a "contenttype" parameter with "wiki", "velocity", "groovy", etc.
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thomas Mortagne wrote:
On Mon, Feb 9, 2009 at 20:53, Jerome Velociter <jerome@xwiki.com> wrote:
Hello,
First, agreed with Thomas, we should make this generic and allow to define macros with all script languages we support.
Actually I think we should even support wiki content as macro content, you can always execute script if needed using {{velocity}}, {{groovy}} but it's more generic, more consistent with "all is wiki"
I see your point here. I think velocity + html are going to be a strong use cases for those macros, but wiki content makes it more powerful and allows both. (and writing velocity+html as such macro, you write {{velocity}}{{html}} just once so that's ok). This will allow nice wiki macros a la wikimedia templates.
, it makes the code behind the scene much more simple since it will just render the macro content with macro parameters in the context and anyway we need to indicate the content syntaxid to be able to parser the result of execution. If we really need a way to have just script in content we could always have a "contenttype" parameter with "wiki", "velocity", "groovy", etc.
After some thoughts, I don't think it's even needed. Less might be more here, users/developers that are going to write script macros understand well wiki syntax and will have no problem writing {{velocity}} or {{html}} when needed. What is going to be important is the way we present and explain it in the MacroClassSheet in inline form edition mode, so that it's clear what is allowed inside ; also explain that parameters are here just for macros that have script(s). Jerome.
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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). 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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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 <vincent@massol.net> 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
On Tue, Feb 10, 2009 at 09:46, Vincent Massol <vincent@massol.net> 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.
This means we could not use directly ComponentManager to get a macro but instead use a MacroManager which would try wiki and ComponentManager.
-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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Jerome Velociter wrote:
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.
Oups, did not read correctly. As Thomas says, if we do that, the rendering should be adapted and not rely uniquely on the component manager. Jerome.
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Feb 10, 2009 at 10:55, Jerome Velociter <jerome@xwiki.com> wrote:
Jerome Velociter wrote:
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.
Oups, did not read correctly. As Thomas says, if we do that, the rendering should be adapted and not rely uniquely on the component manager.
We could maybe make the ComponentManager able to register multiples ComponentSource and plexus would just be one ComponentSource and we could register a WikiMacroComponentSource
Jerome.
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (3)
-
Jerome Velociter -
Thomas Mortagne -
Vincent Massol