June 2009 - Zope-Dev

z3c.saconfig engine creation configuration
by Malthe Borch 25 Jun '09

25 Jun '09

On MySQL, it's necessary to supply to ``pool_recycle`` parameter on engine creation, else the connection dies after some timeout and the pool is unable to hand out a session. The result of this is that the first request fails whenever the connection has been dropped. Attached is a patch that allows supplying these pool-related configuration options directly in the ZCML directive (db:engine). \malthe Index: src/z3c/saconfig/zcml.py =================================================================== --- src/z3c/saconfig/zcml.py (revision 101264) +++ src/z3c/saconfig/zcml.py (working copy) @@ -27,13 +27,31 @@ required=False, default=False) + pool_size = zope.schema.Integer( + title=u"Pool size", + description=u"Number of connections to keep open inside the connection pool.", + required=False, + default=5) + + pool_recycle = zope.schema.Integer( + title=u"Pool recycle", + description=u"Recycle connections after the given number of seconds have passed.", + required=False, + default=-1) + + pool_timeout = zope.schema.Integer( + title=u"Pool timeout", + description=u"Number of seconds to wait before giving up on getting a connection from the pool.", + required=False, + default=30) + setup = zope.schema.BytesLine( title=u'After engine creation hook', description=u'Callback for creating mappers etc. One argument is passed, the engine', required=False, default=None) + - class ISessionDirective(zope.interface.Interface): """Registers a database scoped session""" @@ -62,8 +80,11 @@ default="z3c.saconfig.utility.GloballyScopedSession") -def engine(_context, url, name=u"", echo=False, setup=None, twophase=False): - factory = utility.EngineFactory(url, echo=echo) +def engine(_context, url, name=u"", echo=False, setup=None, twophase=False, + pool_size=5, pool_recycle=-1, pool_timeout=30): + factory = utility.EngineFactory( + url, echo=echo, pool_size=pool_size, + pool_recycle=pool_recycle, pool_timeout=pool_timeout) zope.component.zcml.utility( _context,

2 2

zope.testbrowser without the http requests
by Chris Withers 24 Jun '09

24 Jun '09

Hi All, I'm doing some functional testing of controllers in a Pylons project and I'm wondering if zope.testbrowser can be used for just analysing html rather than actually issuing the http requests? If not, is there anything similar that can? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

fail loading persistentregistry
by Jean-François Roche 24 Jun '09

24 Jun '09

Hello, Within zope2 (2.10.6) I can't load the pickle containing the persistentregistry any more because I removed a product that has persistent adatpers. So I am having a state that looks like this: {'LookupClass': <class 'five.localsitemanager.registry.FiveVerifyingAdapterLookup'>, '__bases__': (<zope.component.globalregistry.GlobalAdapterRegistry object at 0x7f38ad2f6bd0>,), '__parent__': <PersistentComponents /m00019/prsi>, '_adapters': [{<InterfaceClass Products.ATContentTypes.interface.interfaces.IATCTTool>: {u'': <ATCTTool at portal_atct>}, <InterfaceClass Products.CMFActionIcons.interfaces._tools.IActionIconsTool>: {u'': <ActionIconsTool at portal_actionicons>}, <class 'clearwind.arecibo.interfaces.IAreciboConfiguration'>: {u'Arecibo_config': <AreciboConfiguration at broken>}, <InterfaceClass plone.app.i18n.locales.interfaces.IContentLanguages>: {u'': <ContentLanguages at plone_app_content_languages>}, ...] '_generation': ..., '_provided': ..., '_subscribers': ..., } Clearly this registry is in bad shape because of the reference to the broken interface. What are my options to remove the reference within this pickle ? Would it be possible disable/remove (before setstate) the broken class from the registry (with a huge warning) instead of letting the user get a "AttributeError: type object 'IAreciboConfiguration' has no attribute '__iro__' exception" later on when the adapter is looked up ? Thanks in advance, Jeff

1 0

Zope Tests: 8 OK
by Zope Tests Summarizer 24 Jun '09

24 Jun '09

Summary of messages to the zope-tests list. Period Tue Jun 23 12:00:00 2009 UTC to Wed Jun 24 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: Tue Jun 23 21:12:45 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/012011.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Jun 23 21:14:45 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/012012.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Tue Jun 23 21:16:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/012013.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Tue Jun 23 21:18:54 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/012014.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Tue Jun 23 21:20:54 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/012015.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue Jun 23 21:22:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/012016.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Tue Jun 23 21:24:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/012017.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Tue Jun 23 21:26:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-June/012018.html

1 0

Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
by Tres Seaver 24 Jun '09

24 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fabio Tranchitella wrote: > Zope 2 and Plone > ================ > > Zope 2 and Plone are obviously related, so the future of one of the two > influences the other one. > > The main problem for Zope2 is that the current stable upstream branch > (2.12) still requires python2.4. Incorrect: Zope 2.12 is supported only on Python 2.5 / 2.6. The INSTALL.rst[1] file says: Prerequisites ------------- System requirements when building from source - A supported version of Python, including the development support if installed from system-level packages. Supported versions include: * 2.5.x, (x >= 4) * 2.6.x - Zope needs the Python ``zlib`` module to be importable. If you are building your own Python from source, please be sure that you have the headers installed which correspond to your system's ``zlib``. - A C compiler capable of building extension modules for your Python (gcc recommended). > This is not acceptable in Debian and > Ubuntu, and Zope 2 is right now the only stopper for the removal of > python2.4 from both Debian and Ubuntu. > > Even worse, the current stable Plone releases requires Zope 2.10, which we > suppose will never support anything but python2.4 in the foreseeable > future. The new major upstream branch (Plone 4) is still far from being released, which means > that the only way to support Plone and Zope 2.x in Debian and Ubuntu is to > keep python2.4 in the distribution. Plone 4.0 is slated be released this year, with an explicit goal of running on Zope 2.12 / Python 2.{5,6}][1]. > For this reason, together with the upstream suggestions to use the unified > installer and zc.buildout as primary tools for deploying Zope 2 and Plone, > the Debian/Ubuntu Zope Team decided to drop support for Zope 2, Plone and > all the other Zope 2 products. We will file requests of removal for all the > Zope and Plone packages from the archive. In the short term, I would just update the existing packages to use Python 2.5, which is "known to work" with Zope 2.10. [1] http://svn.zope.org/Zope/branches/2.12/doc/INSTALL.rst?view=auto [2] http://article.gmane.org/gmane.comp.web.zope.plone.teams.framework/2767 Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKQTj2+gerLs4ltQ4RAksHAJoDgFLtBHjATSgNhIstWOjWeHSuAgCfevxM v0hySbVNf1nbrL8GzyBqKcU= =w/ik -----END PGP SIGNATURE-----

4 5

Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
by Balazs Ree 24 Jun '09

24 Jun '09

On Tue, 23 Jun 2009 16:15:12 +0200, Fabio Tranchitella wrote: > Hello all! > > In the last couple of weeks Brian Sutherland, Matthias Klose and I > worked together to improve the Zope packaging for Debian and Ubuntu. > This e-mail summarizes the problems we faced, the decisions that have > been taken and the changes that we will upload to experimental and > unstable in the next weeks. > > Short summary > ============= > > We switch from a monolithic Zope 3 package to individual packages for > the libraries that are part of the ZTK (Zope Toolkit). Zope instance > management tools are not supported anymore, as we suggest the use of > WSGI. > > We also drop support for Zope 2 and Plone in Debian and Ubuntu, asking > for the removal of the packages from the distribution. I am certainly one person that did use the Debian packages at the time when people first started to suggest against it. I dropped this habit when I needed to work most of the time with custom Zope and Plone versions that were too new or too rare to be in Debian yet. But I'm still using Debian's python2.4 right now to bootstrap my buildouts. > The main problem for Zope2 is that the current stable upstream branch > (2.12) still requires pthon2.4. This is not acceptable in Debian and > Ubuntu, and Zope 2 is right now the only stopper for the removal of > python2.4 from both Debian and Ubuntu. What's the reason for the removal of python2.4? Is there a technological reason, or is this a policy decision? Don't forget that Plone users, who are also the biggest consumer group of Zope / ZTK, still will be users of 2.4 for a while. The unified installer is not the only installation method used for Plone, in fact many users and the majority of deployments use python + buildout. These users will need to read documentation and do installation to be able to bootstrap their buildout, which is not exactly a reason for them to choose Debian / Ubuntu in this case. -- Balazs Ree

3 2

RFC: ZTK custom publications, zope.app.publication, and zope.traversing
by Jim Fulton 23 Jun '09

23 Jun '09

I'm trying to make the Zope Toolkit (ZTK) publisher/publication framework a little easier to deal with. I think zope.app.publication mostly provides a generally useful publication implementation. It has 2 problems: - Its getApplication method digs a particular object out of a ZODB database. Some people would like the flexibility of not using ZODB. - It aggressively proxies objects using zope.security.checker.ProxyFactory. Some people don't want to use proxies and those that do might want to use a different proxy or checker implementation. It was already possible for a subclass to override getApplication fairly cleanly. (This also entailed overridding __init__ in a pretty simple way.) I made it possible to override proxying by overriding the proxy method. At this point, I think zope.app.publication provides a pretty reasonable base class for custom publication implementations, although the module arrangement could be made a bit simpler. In working on this, I've found the implementation and tests of zope.app.publication to be split between zope.app.publication and zope.traversing. I want to sort this out, but I'm not certain what the intent if zope.traversing is. I think the intent has become muddled over time, if it was ever clear in the first place. :) Early on, we mixed up ZPT path traversal and URL traversal. These are similar, but different. There are features you want in ZPT traversal, like the resource namespace that you don't want in URL traversal. Similarly, you want features like virtual host support and default pages in URL traversal but not in ZPT traversal. Early on, we used path traversal in many places, not just ZPT, which is probably why most of the code in zope.traversing isn't in zope ZPT- related package. Early on, we decided that the menu framework should be able to filter menu items based on whether the user could traverse to an item. On some level, this was reasonable because it made menu specifications simpler, but it adds great expense and complexity. I'm not sure anyone in the know uses the menu framework anymore. If they are and aren't specifying permissions on their menu items, they are being helped to do the wrong thing. Originally, zope.app.publication defined a base class, PublicationTraverse, that provided traverseName. Even though I may have done this, I don't know why this was broken out into a separate base class. I don't think anyone else is subclassing this, but I don't know. I propose the following: In phase 1 reduce the scope of zope.traversing: - Move path traversal code to zope.tales - Move the URL traversal code used by zope.app.publisher.menu to zope.app.publisher.menu. Refactor it to use the request.publication. Deprecate definition of menu items without permissions. - Move the virtual host and skin tests from zope.traversing to zope.app.publication. The only things left, I think will be the namespace framework and the absolute-url support. (Both of these could use more thought, but I've used up my thinking budget for this morning. :) In phase 2, simplify the class tree in zope.app.publication Merge zopepublication, http, browser, and xmlrpc. traverse using request.method when request,method isn't one of GET, HEAD, or POST. Maybe in phase 3: - Create zope.publication from zope.app.publcatiobn - use webtest rather than zope.app.testing. - Maybe provide a paste deployment mechanism for easily assembling publisher-based appls based on prototype work I'm doing in zc.publication. Thoughts? Jim -- Jim Fulton Zope Corporation

7 19

zope.testrunner import location notifications
by Martijn Faassen 23 Jun '09

23 Jun '09

Hi there, (in particular Christian Theune) What's the status of the 'import location' notification functionality in zope.testrunner? What's the status of the ZODB migration code? Regards, Martijn

2 3

Zope Tests: No messages
by Zope Tests Summarizer 23 Jun '09

23 Jun '09

Summary of messages to the zope-tests list. Period Mon Jun 22 12:00:00 2009 UTC to Tue Jun 23 12:00:00 2009 UTC. There were no messages.

1 0

hurry.workflow class based work flows.
by Michael Shaw 23 Jun '09

23 Jun '09

Hello, I have been working with hurry.workflow in a project and had some questions about making hurry.workflow work with different work flows. For this project each class can have a different work flow with it's own set of states and transitions. All of the instances of a given class share the same work flow. To create these different work flows I have registered a utility for each class. The utility has a factory that creates instances of hurry.workflow.workflow.Workflow initialized with the correct set of transitions for that type. The utilities are named, to allow more than one utility to register for the hurry.interfaces.IWorkflow interface. With many IWorkflow utilities the WorkflowInfo implementation can not find the utility it needs. So I changed the WorkflowInfo behavior by having it look for a named utility based on the class name of the instance. For example the work flow utility for the class 'Cat' is registered with the name "project.workflow.Cat" which I selected the pattern "project.workflow.{className}" to try and avoid naming conflicts. This solution seems to work well for the project I am working on, however I am quite new to Zope and this is the first time I've made these kinds of modifications. Does anyone have any thoughts about how this implementation could be improved, it doesn't feel like I'm taking the best advantage of the component model? If I could come up with a set of patches, would the change to a class based work flow be useful to include in hurry.workflow? Regards, Michael -- ******************************************** Michael Shaw Developer Nunatak Systems Pty Ltd 15 Princes Street Sandy Bay Tasmania 7005 Australia P: 61 3 6223 7875 F: 61 3 6226 1887 e: michael.shaw(a)nunatak.com.au w: www.nunatak.com.au ********************************************

2 1