2 Jun
2014
2 Jun
'14
7:09 p.m.
On 06/02/2014 12:57 PM, vincent(a)massol.net wrote:
On 2 Jun 2014 at 18:49:53, Sergiu Dumitriu (sergiu@xwiki.com(mailto:sergiu@xwiki.com))
wrote:
> On 06/02/2014 12:46 PM, vincent(a)massol.net wrote:
>> Note: Maybe it’s time to think about a generic mapping between naming rules from
xwiki.properties and naming rules from xproperties (eg XWikiPreferences properties)...
>
> How about this for a rule:
>
> Stop adding properties to XWikiProperties!
s/XWikiProperties/XWikiPreferences/
Well you need to explain your thoughts more :)
The goal of xwiki.properties is to:
- define config values even when there’s no wiki page
- define config values for all wikis
Also note that we have a global Configuration system. You just ask for a property value
knowing it’s name and it’ll find it for you by looking in all places. Those places are
configurable (it can be in a properties file, in LDAP, in a DB, in wiki pages, etc).
The issue I was raising is that we’re naming properties with
“<module>.<name>[.<subname>]” in xwiki.properties while this is not a
current convention in xproperties (actually we don’t have any convention ATM for xproperty
naming AFAIK, sometimes it’s with “_” as in “smtp_host”, sometimes it’s in camelcase as in
“displayHiddenDocuments" , sometimes with “.” as in “xwiki.preferences.redirect”).
Yes, xwiki.properties is good, no objection to that.
XWikiPreferences, on the other hand, is not scalable.
- It is close to the limit of what can be stored in
xwikidoc.XWD_CLASSXML, so besides what we currently have in the default
class, users can add only a few more properties.
- Telling users (be they admins, so hopefully a bit more knowledgeable
than normal users) to open the class editor on XWikiPreferences (which
is not easily accessible, by the way) and add a specific type of
property, then open the object editor to set a value for it, is not user
friendly at all, and leaves a lot of room for errors.
- Adding them to XWikiPreferences means that they automatically appear
in the space preferences as well, although not all preferences are taken
into account at the space level. Thus, users might be confused by
settings that don't work...
The direction taken by Configurable sections is scalable, but it is not
fully usable at the moment, since reading these settings requires custom
code. I would invest into making it easy to read custom settings instead
of describing how "new" XWikiPreferences properties should be named.
There is no more space left for new xproperties.
--
Sergiu Dumitriu
http://purl.org/net/sergiu