Hi everyone,
On 28/06/2019 21:32, Thomas Mortagne wrote:
On Fri, Jun 28, 2019 at 7:12 PM Vincent Massol <[email protected]> wrote:
On 28 Jun 2019, at 19:10, Vincent Massol <[email protected]> wrote:
Hi Simon,
On 28 Jun 2019, at 18:56, Simon Urli <[email protected]> wrote:
Hi everyone,
this is a proposal to add a new wikimacro script binding for the next release,
that I also plan to backport on 11.3.x and 10.11.x branches.
We had recently a bug report (https://jira.xwiki.org/browse/XWIKI-16520) about
the WikiMacro parameter: types were introduce in 10.10 (with
https://jira.xwiki.org/browse/XWIKI-13282) but we in fact never converted them,
making their type pretty useless.
We provided a first fix to it actually broke at least one existing macro,
AttachmentSelector which was still expecting String parameter values instead of
the types used in some of those parameters.
So even if the parameters were supposed to be typed since XWiki 10.10, in
practice they never have been. We might as well consider returning a typed
values as a regression since it might break some of the existing macros.
That's why I propose to implement right now a new wikimacro binding, to be able
to get both typed parameter values and string parameter values.
The old binding would then still be available by using $xcontext.macro but we
would deprecate its usage.
I propose that all the existing $xcontext.macro information to be available by
using $macro, and to be able to use:
* $macro.parameters.foo to get a typed parameter value
+1, we chose params in the previous binding because it's shorter and I
don't really have anything against it either
So I did the implementation for this binding, as a matter of fact I had
to use
$wikimacro instead of $macro because "macro" is already a reserved
binding for velocity.
So $wikimacro have the same objects as $xcontext.macro except params
which is now parameters and contains converted values.
The work is done as part of https://jira.xwiki.org/browse/XWIKI-16549.
Simon
* $macro.parametersAsString.foo to get the string value parameter
I don't think we really need that. Also it does not make much sense
from API point of view since the input parameter value before
conversion is not String but Object, macros coming from a wiki source
will be Strings but it's just a use case.
If we want to provider devs with a way to get the String
representation of any property we can introduce a
$services.properties.toString($value) for example.
Could you tell me if you agree with all those changes?
Sounds good.
Actually I’m hesitating because we said we didn’t want to expose bindings
directly in the velocity context.
So $services.macro might be better since $services is reserved.
Imagine an existing wiki macro doing:
#set ($macro = “….”)
You would break it.
Why ?
It's not because the macro binding is already set before the execution
of the macro that the #set will crash.
Thanks
-Vincent
I’m wondering if I wouldn’t prefer the following:
* $macro.parameters.foo.value() <- typed
-1, it's way too complex for what is supposed to be the thing you want
to to pretty much all the time
* $macro.parameters.foo.rawValue() or toString() <- string, as specified by the
user when using the macro
$macro.parameters.foo would return some MacroParameter object.
Note that $macro.parameters.foo when used in a string context would call
$macro.parameters.foo.toString() which would return the raw value.
Thanks
-Vincent
Thanks,
Simon
--
Simon Urli
Software Engineer at XWiki SAS
[email protected]
More about us at http://www.xwiki.com
--
Simon Urli
Software Engineer at XWiki SAS
[email protected]
More about us at http://www.xwiki.com
