optilude+lists at gmail
Jun 5, 2009, 5:31 AM
Post #15 of 15
(1289 views)
Permalink
|
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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
|
signature.asc
