15 Nov
2018
15 Nov
'18
6:29 a.m.
On Wed, Nov 14, 2018 at 5:12 PM Vincent Massol <vincent(a)massol.net> 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
<
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
>