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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
