Proposal: Add display options in the property descriptor

Hi!

Context

For XWIKI-23834: Add pickers for the notification macro, I’m improving the way we define the properties of the notification macro. Currently for each property, a picker is used matching its type. Using the same picker for many fields can work, but sometimes the existing picker does not match exactly what would be expected for the best UX in the context.

This proposal targets the PropertyDescriptor of xwiki-commons-properties.

Proposal

Add display options in the property configuration. This optional parameter would be a Map from String to String.

Explanation

Currently, the property descriptor only describes how the property fits regarding the other properties and in the structure in which it’s included (for XWiki, the macro). However, the property is also meant to be displayed, and there’s currently no field that is appropriate to contain information that would allow the property to be displayed in a specific way without a workaround.
I believe that if we already had this option, the displayHidden or even advanced and order parameters would be way less necessary. IMO, instead of continuing to add new parameters in this descriptor for every specific use case, we can use a generic map to contain all this information that is only important when actually displaying the property.

On XWiki’s side, it would make it significantly easier to reuse and extend existing picker templates.
E.g.: in a macro, I have a “project handler”. UI wise, it’s just a standard user, but since I have a few other user to pick with different roles, I want to highlight this one as the most critical with red. Currently, my only way to do this is either:

  • Use a workaround in the template to check the field name and hard-code the field with the name “project handler” to be red.
  • Introduce a new Java child class “ProjectHandler” as a child class of User, use it as the type of my field, and duplicate the edit.vm template

With a display option, we could just provide {“color” = “red”} to the template, and update it so that it uses this option as expected. This is better than hard-coding, because :

  • “project handler” from other macros will not become red too.
  • It’s easy to reuse this system later to make another user picker {“color” = “green”} if needed later.

I believe this improvement would make the system of properties more powerful and in XWiki’s case, easier to use.

Conclusion

Here’s my +1 for this proposal, what do you think of it?

You can get an idea of what the implementation would look like at XCOMMONS-3536: Add parameters for the edit Template in the property descriptor by Sereza7 · Pull Request #1602 · xwiki/xwiki-commons · GitHub .

Thank you for your interest in this proposal!
Lucas C.

Sounds good, +1. I think we should make sure that this is also supported in wiki macros, probably with a properties syntax similar to parameters in UI extensions (but I’m not sure if we really need Velocity support in those parameters, so maybe better don’t support Velocity).

As an additional comment, while I agree with the proposal as mentioned before, I don’t agree that those options could have avoided the advanced or order options. I think we should distinguish between common options that are supported by all macro parameters that influence the macro dialog and options that are for the displayer of the chosen property type. I don’t think that mixing those two is a good idea. Further, a raw options map seems fitting for a displayer that is written in Velocity, but while flexible, it is also error-prone, and I would thus avoid this approach if we have a better way that provides more validation, e.g., for the used option names.

+1

IMO we don’t need velocity support in here. We could still use this Map to set some boolean flags and “hard-code” things in the velocity templates if really needed.

+1 for the concept

StaticListClass seems to have support for retrieving a map, but does not seem to provide a dedicated editor/displayer (other that plain input).