On Tue, Apr 28, 2009 at 16:12, Jerome Velociter <jerome(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne