[Zope-dev] release zope.testing?
Hello, I've recently fixed two bugs in zope.testing that I find annoying on an almost daily basis (commandline option -1 doesn't work and readline is broken in pdb). Could someone review the changes on the trunk and cut a release of zope.testing? Thanks, Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] refactoring site functionality
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@zope.org 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 )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Thu Jun 4 12:00:00 2009 UTC to Fri Jun 5 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Jun 4 20:47:01 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/011867.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Jun 4 20:49:03 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/011868.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu Jun 4 20:51:03 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/011869.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu Jun 4 20:53:03 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/011870.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Thu Jun 4 20:55:03 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/011871.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Jun 4 20:57:04 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/011872.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu Jun 4 20:59:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/011873.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Thu Jun 4 21:01:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/011874.html ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] refactoring site functionality
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. And the configuration UI itself could become simpler or at least less scattered around, so that's a win. 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). 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?] Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] refactoring site functionality
Chris McDonough wrote: > On 6/4/09 11:59 AM, Martijn Faassen wrote: [snip] >> I don't think it's complicated. It's nice to install an object somewhere >> that stores data and has a UI and also be able to register it as a local >> utility. If you were to have mutable global configuration, you'd need >> some way to expose it to the UI and content-space too. > > This is true. OTOH, I've never really been keen on the idea that the CA API > should be bent around the idea that you're going to often want to find a > persistent registry. It seems just as reasonable to: > > - put a persistent object someplace (with its own UI) that isn't registered as >a CA utility. > > - find it via the location API when you need it in your code. By location API, you mean something like mycurrentapp()['foo']['bar']? > - *Pass* it to global utilities (or adapters) when you need to vary behavior >based on location. Doesn't this make you have to scatter a lot of location-getting and context-passing code throughout your codebase? I guess it depends on how your codebase is factored. But say you have a utility that sends email, and can be configured with the email address to send it to somewhere in a config screen, you could have 10 places in your code that need to get the configured email address and then pass it to the utility. Now that's probably easy enough to encapsulate in a function, but: * but if you have your configuration right there in the local utility it comes pre-encapsulated. Now you got two bits, one that knows how to send email and one that is being configured. This separation into bits may be right in some cases, but it seems overkill in many. * you're going to have to pass your current application context in each time you want to send email. That's avoided with a utility lookup (as this is implicit). So, I'm having trouble seeing the benefits to this alternative approach, could you explain? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
