On 2 Jun 2014 at 19:09:37, Sergiu Dumitriu
([email protected](mailto:[email protected])) wrote:
> 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/
ok that changes your email completely :)
We all agree about not increasing the XWikiPreferences size and instead
breaking down all configs by module (each module coming with its own Config
page(s)).
However my comment wasn’t about XWikiPreferences at all. I said "mapping
between naming rules from xwiki.properties and naming rules from xproperties
(eg XWikiPreferences properties)”. I was using XWikiPreferences as an example
only.
Not sure what’s your point here WRT my question :)
Thanks
-Vincent
> > 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 “.[.]” 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
