3 Jul
2019
3 Jul
'19
9:35 a.m.
On Wed, Jul 3, 2019 at 8:39 AM Simon Urli <simon.urli(a)xwiki.com> wrote:
Hi everyone,
On 28/06/2019 21:32, Thomas Mortagne wrote:
Note: it's not the same object, Simon just mean the same bindings are
exposed in both objects.
On Fri, Jun 28, 2019 at 7:12 PM Vincent Massol
<vincent(a)massol.net> wrote:
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.
> On 28 Jun 2019, at 19:10, Vincent Massol <vincent(a)massol.net> wrote:
>
> Hi Simon,
>
>> On 28 Jun 2019, at 18:56, Simon Urli <simon.urli(a)xwiki.com> 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
The work is done as part of https://jira.xwiki.org/browse/XWIKI-16549.
Simon
Why ?
It's not because the macro binding is already set before the execution
of the macro that the #set will crash.
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
--
Thomas Mortagne
>> * $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.
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
> simon.urli(a)xwiki.com
> More about us at http://www.xwiki.com