On Wed, Nov 14, 2018 at 5:12 PM Vincent Massol <[email protected]> wrote:
> I thought about something like this but I discarded it as I find this > complicated for something that should be relatively simple. 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 < > [email protected]> 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 <[email protected]> > > 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 > >> > >
