On Fri, Jun 28, 2019 at 7:12 PM Vincent Massol <vinc...@massol.net> wrote: > > > > > On 28 Jun 2019, at 19:10, Vincent Massol <vinc...@massol.net> wrote: > > > > Hi Simon, > > > >> On 28 Jun 2019, at 18:56, Simon Urli <simon.u...@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. > > 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 > >> simon.u...@xwiki.com > >> More about us at http://www.xwiki.com > -- Thomas Mortagne
