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