Re: [xwiki-devs] [Need proposal] How to show "conflicting" macro parameters

On 15 Nov 2018, at 06:29, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> wrote: On Wed, Nov 14, 2018 at 5:12 PM Vincent Massol <vincent(a)massol.net> wrote: I don't think it's that complicated because: * Conflicting parameters should be an exception, not the rule. What other macros, besides include / display, need this? * If you just want to group macro parameters for display then you only need to use the @Group annotation. You don't need to implement a ParameterGroup. The ParameterGroup is needed only for conflicting parameters (ATM).

Thanks, Marius > I’d prefer to have some simple annotations if possible. In other words, if > feels a bit of over-engineering for the need. Now I have to admit that I > stopped following this thread after the original proposal so maybe I’m just > completely off :) > > Thanks > -Vincent > >> On 14 Nov 2018, at 15:51, Marius Dumitru Florea < > mariusdumitru.florea(a)xwiki.com&gt; wrote: >> >> WDYT about: >> >> -----8<----- IncludeMacroParameters ---------- >> @Group("target") >> page >> >> @Group("target/entityReference") >> reference >> >> @Group("target/entityReference") >> type >> >> @Group("target") >> document >> >> section >> >> context >> ----->8--------------- >> >> That is: specify *only* the group hierarchy in the macro parameter >> descriptor. This would produce the following hierarchy: >> >> * <target> >> ** page >> ** <entityReference> >> *** reference >> *** type >> ** document >> * section >> * context >> >> Next, for the cases where we want to customize the behavior of a group, > we >> introduce a component role ParameterGroup. For instance, for the "target" >> parameter group of the Include Macro we would create >> >> @Named("include/target") >> public class TargetParameterGroup implements ParameterGroup {} >> >> To specify that the members of a parameter group are exclusive we can >> either use a method in the ParameterGroup interface (e.g. isExclusive()) > or >> use an annotation on the implementation TargetParameterGroup. >> >> Thanks, >> Marius >> >> >> On Tue, Nov 13, 2018 at 12:03 PM Adel Atallah &lt;adel.atallah(a)xwiki.com&gt; >> wrote: >> >>> Hello, >>> >>> I'd like to briefly summarize the situation so that we can make some >>> progress. >>> >>> What we have: >>> * We define "parameters" in a macro by creating a Java Bean, which >>> provides all the getters and setters of the parameters we want. >>> * We can use annotations on these getters/setters to define some >>> behavior or metadata for these parameters (description, mandatory, >>> deprecated...) >>> >>> What we want: >>> * Being able to handle conflicting parameters. For instance when we >>> deprecate a parameter and add a new one to replace it, we should be >>> able to either use the deprecated parameter or the new one but not >>> both. >>> * We also want to group parameters that are related to each other. >>> >>> What we proposed: >>> * Use annotations on the parameters to express the conflict. >>> * Marius proposed to see the problem as a boolean expression such as: >>> (page XOR (reference AND type) XOR document) OR section OR context. >>> This would translate as: the user can use the 'section' and/or >>> 'context' parameters (if they want), can use only one of these >>> parameters: 'page', ('reference' and 'type') or 'document', where >>> 'reference' and 'type' depend on each other and you can't use one >>> without the other. >>> * You can see on previous e-mails the kind of annotations we proposed >>> to solve the issue. >>> >>> Thanks, >>> Adel >>> > >