I thought about something like this but I discarded it as I find this complicated for something that should be relatively simple. 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 >>
