[xwiki-devs] In-wiki macros : generic wiki macro, or bridged script macros or selectable implementation ?
Hi devs, I'm going to continue the work on allowing users to write syntax 2.0 macros inside the wiki (http://jira.xwiki.org/jira/browse/XWIKI-3213) We have several implementations possible for this: 1. Having only one generic wiki macro implementation. This means macro authors will have to call explicitly the velocity macro inside if they need velocity scripting (same for other script languages) * Pros: - You can use wiki syntax in your macro. This is cool, it enables doing things like wikipedia templates (http://en.wikipedia.org/wiki/Help:Template) - We can easily provide the GWT-WYSIWYG to macro authors. This is an idea I like - It sound pretty natural to do it this way * Cons: - We'll have to put macro parameters in the XWiki context so that they are available to all script macros used in the macro. It means authors will have to refer to parameters using $context.get("parameterName") instead of $parameterName that would be doable with 2. 2. Writing one implementation per script language. This means authors will create a velocity macro and will write directly velocity code in the code are of the macro. * Pros: - Parameters don't need to be passed in the XWiki context (at least I think, if I'm wrong please explain me/us why) * Cons: - We'll have several XWiki classes, one per supported scripting language (XWiki.VelocityMacroClass, XWiki.GroovyMacroClass, etc.) - We cannot use wiki syntax in any implementation, so we cannot do the wikipedia templates-like thing 3. Keep for ourselves the ability to chose from the wiki the implementation class of the macro, but default on 1. the generic script macro. This means we will have a "class" field in the XWiki.MacroClass which allows to chose which implementation should be the code rendered against. If we do that I think this field should be hidden in the class sheet, and only be accessible using the object editor. This is similar to the way Scheduler Job objects works right now. * Pros: - Best of both world, we can have 1. and 2. - Leaves open the door for new macros implementations we could want in the future, or that developers would want just for their wiki * Cons: - Probably a little more code to handle that Right now, I tend to think we should do 3. with only one implementation available at first, being the generic wiki macro described in 1. WDYT ? Thanks in advance for your feedback. Cheers, Jerome.
On Tue, Apr 28, 2009 at 16:12, Jerome Velociter <[email protected]> wrote:
Hi devs,
I'm going to continue the work on allowing users to write syntax 2.0 macros inside the wiki (http://jira.xwiki.org/jira/browse/XWIKI-3213)
We have several implementations possible for this:
1. Having only one generic wiki macro implementation. This means macro authors will have to call explicitly the velocity macro inside if they need velocity scripting (same for other script languages)
* Pros: - You can use wiki syntax in your macro. This is cool, it enables doing things like wikipedia templates (http://en.wikipedia.org/wiki/Help:Template) - We can easily provide the GWT-WYSIWYG to macro authors. This is an idea I like - It sound pretty natural to do it this way
* Cons: - We'll have to put macro parameters in the XWiki context so that they are available to all script macros used in the macro. It means authors will have to refer to parameters using $context.get("parameterName") instead of $parameterName that would be doable with 2.
2. Writing one implementation per script language. This means authors will create a velocity macro and will write directly velocity code in the code are of the macro.
* Pros: - Parameters don't need to be passed in the XWiki context (at least I think, if I'm wrong please explain me/us why)
* Cons: - We'll have several XWiki classes, one per supported scripting language (XWiki.VelocityMacroClass, XWiki.GroovyMacroClass, etc.) - We cannot use wiki syntax in any implementation, so we cannot do the wikipedia templates-like thing
3. Keep for ourselves the ability to chose from the wiki the implementation class of the macro, but default on 1. the generic script macro. This means we will have a "class" field in the XWiki.MacroClass which allows to chose which implementation should be the code rendered against. If we do that I think this field should be hidden in the class sheet, and only be accessible using the object editor. This is similar to the way Scheduler Job objects works right now.
* Pros: - Best of both world, we can have 1. and 2. - Leaves open the door for new macros implementations we could want in the future, or that developers would want just for their wiki
* Cons: - Probably a little more code to handle that
Right now, I tend to think we should do 3. with only one implementation available at first, being the generic wiki macro described in 1.
WDYT ? Thanks in advance for your feedback.
+1 for 3 -1 for 2: having $var instead of $context.var is not enough IMO considering all the cons. Also 1. is following the simple rule all is wiki and it's more consistent for a user to have the same way of working everywhere. Also macro does not always means scripting, the macro could simply be a generated content which is always the same and can be change easily for each page using the macro, like a specific page header/footer, etc...
Cheers, Jerome. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (2)
-
Jerome Velociter -
Thomas Mortagne