Hi Martijn, Martijn Faassen wrote:
Hi there,
Wichert Akkerman wrote: [snip]
For Plone we regret that we used persistent utilities to store configuration: they have made Plone instances much more fragile (removing a utiliy's implementation breaks the whole site) and forces you to write a UI for the stored configuration again and again. To move forwards we have come up with plone.registry (see http://pypi.python.org/pypi/plone.registry), which gives you a nice central storage system for configuration.
That's very interesting!
I can see the benefits of separating this out, though on the other hand it does introduce more indirection, which is a cost as well.
I'm not sure that it does, as such. It's more of a conceptual change. The plone.registry model is kind of like about:config in Firefox. You have a place to create configuration records (values with a schema) and a way to retrieve them. There's still only one level of indirection: find the thing that stores your values, and get them. It's just that instead of calling getUtility(IMyUtility) you call getUtility(IRegistry) and get the values from there. You can, if you want, build your records from a schema for convenience, and get back an object conforming to that schema backed by the registry. However, the registry does not contain any persistent references to your custom code, so it doesn't break if that symbol is no longer importable. plone.app.registry adds a GenericSetup synax + a generic config editor + a base class for building custom "control panel" forms based on the registry.
And the configuration UI itself could become simpler or at least less scattered around, so that's a win.
At least you can generalise the things that you don't need to expose the user. Like Firefox, there's a control panel for the user-facing stuff, and about:config as a geeky fallback.
I can see how this cost is worth it in large apps like Plone. I'm not sure about smaller apps, but could be a win too, as you could reuse the configuration UI. The costs can also be minimized with the use of a proxy (I saw you have one).
Right. There's some value in standardising on a pattern, too. I think if you want some kind of persistent configuration, plone.registry or something like it adds useful consistency and safety. If you don't want persistent configuration, it's obviously moot.
It's definitely an interesting approach. I'll be keeping an eye on it...
[it's licensed GPL at the moment the pypi page says. Is this going to change?]
Yes, as soon as the Plone Foundatino licensing changes are completed, this will be BSD licensed. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book