28 Jun
2019
28 Jun
'19
6:56 p.m.
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
* $macro.parametersAsString.foo to get the string value parameter
Could you tell me if you agree with all those changes?
Thanks,
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
28 Jun
28 Jun
7:10 p.m.
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
* $macro.parametersAsString.foo to get the string value parameter
Could you tell me if you agree with all those changes?
Sounds good. I’m wondering if I wouldn’t prefer the following:
* $macro.parameters.foo.value() <- typed
* $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
7:12 p.m.
On 28 Jun 2019, at 19:10, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Simon,
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
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
* $macro.parametersAsString.foo to get the string value parameter
Could you tell me if you agree with all those changes?
Sounds good. I’m wondering if I wouldn’t prefer the following:
* $macro.parameters.foo.value() <- typed
* $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
9:32 p.m.
On Fri, Jun 28, 2019 at 7:12 PM Vincent Massol <vincent(a)massol.net> wrote:
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.
--
Thomas Mortagne
> 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
>> * $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.
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
3 Jul
3 Jul
8:39 a.m.
Hi everyone,
On 28/06/2019 21:32, Thomas Mortagne wrote:
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.
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
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.
The work is done as part of https://jira.xwiki.org/browse/XWIKI-16549.
Simon
> 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 >> * $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.
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
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
1894
days inactive
1899
days old
5 comments
3 participants
participants (3)
-
Simon Urli -
Thomas Mortagne -
Vincent Massol