10 Feb
2009
10 Feb
'09
12:28 a.m.
Thomas Mortagne wrote:
On Mon, Feb 9, 2009 at 20:53, Jerome Velociter
<jerome(a)xwiki.com> wrote:
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.
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.
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(a)massol.net> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs