On 06/02/2014 12:57 PM, [email protected] wrote: > > > > > On 2 Jun 2014 at 18:49:53, Sergiu Dumitriu > ([email protected](mailto:[email protected])) wrote: > >> On 06/02/2014 12:46 PM, [email protected] 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
