14 Jun
2017
14 Jun
'17
1:12 p.m.
Hi, devs,
While handling https://jira.xwiki.org/browse/XWIKI-14157 (Display the
default and inherited values in the Administration), I`m trying to come up
with a solution that is applicable more generally and avoid having to
manually patch just the problem at hand.
We could think of this as a 2 piece problem:
1) getting or specifying the default value (or maybe it's more correct to
say default display value?)
2) displaying a form field and handling the default value (view/edit modes)
1) would be much simpler if we only had to handle a flat level class and
its objects, but, for XWikiPreferences, we also have the
"space<space<wiki<xwiki.cfg" inheritance to consider. This inheritance
is
done through the use of various ConfigurationSource implementations that
delegate one to another.
The problem with ConfigurationSource is that, through its use of
getPreference(preferenceName, defaultValue), we end up in proliferating
default values throughout the code, each time we just want the value of
that preference, resulting in a big mess and not knowing what is the
default value for that preference and where it is set.
I was thinking of adding some:
* <T> T getPropertyDefault(String name) method which would allow a
ConfigurationSource to handle by itself the retrieval of the default value
for a property and a
* <T> T getPropertyOrDefault(String name) convenience method for callers to
fallback on the internally-determined default value, without caring what it
actually is.
As an example, this would be useful when calling
$xwiki.getXWikiPreference(...) since we don`t have to specify the default
value in the caller, but it will be retrieved by performing the fallbacks
mechanism space<space<...<wiki<xwiki.cfg.
Still for 1) but for ConfigurableClass sections that rely on a simple
configuration class (or any other form that relies on properties defined by
a class), one idea would be to add a "defaultValue" meta-property (with
associated getter/setter in PropertyClass) in the class that allows
specifying the default value of a property when defining it. This would
allow a displayer to have the default value and properly display it,
instead of weird "---" stuff we do now and all kinds of *fake* values, just
so that the user can select them.
(We may also need a "defaultPrettyValue" or "defaultDisplayValue",
with
associated getter/setter, for things like DBList).
Reminder: We already have a "defaultValue" meta-property for BooleanClass,
so it looks like we had the idea before, just did not take it all the way.
So XWikiPreferences goes more into the "specifying the default value at
display time" workflow, IMO (because we would have to provide the default
value that is retrieved from a "special" mechanism, i.e.
$xwiki.getXWikiPreference(...))... and we should use the "getting the
default value" (from the class property's "defaultValue) as the default
behavior, for simple objects of simple classes.
Finally, for 2), I`m thinking that we might need a way to also pass the
default value to a display() call, overwriting anything else, in order to
support custom fields that get their defaults from external sources or
other mechanisms that don`t involve the XClass and the "defaultValue"
defined there (like XWikiPreferences does, for example, or other custom
stuff).
This also introduces the problem that not everybody might want a default
value proposed in their form for a certain element, so we should also be
able to specify, at display time, if the default value should be proposed
or not.
These optional additions to the display method ("defaultValue",
"defaultDisplayValue", "showDefault", etc.), including the existing
ones
("prefix", "wrappingSyntaxId", etc.) should probably be done with a
new
signature that also takes a map of parameters.
The aim is to rely as much as possible on $doc.display(property,
parameters) when creating forms in XWiki, while also encapsulating the
default value to the location responsible for it, and not to the caller.
WDYT?
Thanks,
Eduard