14 Nov
2018
14 Nov
'18
4:12 p.m.
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
<mariusdumitru.florea(a)xwiki.com> 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 <adel.atallah(a)xwiki.com>
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
>