Zope-Dev September 2009

zope-dev@zope.dev

45 participants
80 discussions

Manuel Beta
by Benji York 14 Jan '11

14 Jan '11

I've just released the first beta of Manuel, my next-generation doctest project. Being that zope-dev has some of the most well-informed users of doctest (and some of the most well-informed non-users of doctest), I'd like to gather feedback from this group before making an announcement to the wider world. Manuel is available from PyPI (http://pypi.python.org/pypi/manuel) with docs, details, and examples at http://packages.python.org/manuel/. I'm interested in any feedback and/or questions you may have be it technical, documentation, or "marketing" (i.e., how do I describe what Manuel does and what benefits it has). -- Benji York Senior Software Engineer Zope Corporation

5 12

zope.testing: Define __add__ for RENormalizing
by Christian Zagrodnick 06 Dec '09

06 Dec '09

Hi, I suggest defining __add__ for zope.testing.renormalizing.RENormalizing which would return a new Checker with the transformers combined. This allow better reuse of those checkers without having to define the patterns separately. Like checker = checker_a + checker_b. Comments? -- Christian Zagrodnick · cz(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development

3 3

Proposal: zope.app.publisher refactoring
by Dan Korostelev 30 Nov '09

30 Nov '09

Hi all. I think it's time to clean the mess in the zope.app.publisher package. Currently it contains many things that could be moved into separate packages or merged with base zope packages. So here's a sketch plan about where to move things: Menu mechanism (the browser:menuItem directive and friends) - move this to the new "zope.browsermenu" package. This should be easy as nothing else in zope.app.publisher seem to depend on menus. Browser view directives (browser:page and friends) - move this to some "zope.browserpage" package and make its structure more clean, so people could understand the magic of browser page class generation. :-) BrowserSkinsVocabulary - this can be moved to zope.publisher.browser and rewritten with zope.schema's SimpleVocabulary not to introduce dependency on zope.componentvocabulary. ManagementViewSelector (the @@SelectedManagementView.html view) - leave it there as is. Resource mechanism (files, directories, etc.) - probably the most complicated code, but it should be easy to move it to the new "zope.browserresource" package. One problem is with PageTemplateResource that introduces a dependency on zope.pagetemplate. It should probably moved to another package, like "zope.ptresource" and made dependent on z3c.ptcompat to support chameleon engine. ModifiableBrowserLanguages implementation - move to zope.publisher.browser. It's the useful thing that won't introduce any new dependencies. "date" fieldconverter - I don't think anyone uses it, I'd leave it there as is and forget about it :) http.zcml - this file contains security declarations for zope.publisher's HTTP-related classes. move them to zope.publisher. xmlprc - move the IXMLRPCView interface and XMLRPCView base class to zope.publisher as a counterpart to zope.publisher.browser.BrowserView. Move MethodPublisher, MethodTraverser, xmlrpc:view ZCML directive to new "zope.xmlrpcview" package. Also I'd merge MethodTraverser with MethodPublisher to make it easier to understand and to decrease number of entities :) IXMLRPCPublisher adapters for zope.container - move them to zope.container. The IBrowserPublisher adapters that are already there, so it won't make things worser. The zope.container package may be refactored later to break dependency on zope.publisher though. IHTTPView and IFTPView interfaces - move that into zope.publisher as a counterpart to IBrowserView. (BTW, shouldn't IBrowserView be a subclass of IHTTPView?) IFTPDirectoryPublisher interface - not sure what's this and where is it used. Probably should be moved to zope.publisher.interfaces.ftp as well. ILogin, ILogout from zope.app.publisher.interfaces.http - looks like these don't really mean anything and are used only in zope.app.security. I'd move them to zope.app.security even without BBB imports (not to make zope.app.publisher dependent on zope.app.security), but maybe I just don't know something about them? :) That's all for now. I'd like to see some comments/propositions/objections before I start. Also, maybe there are more beautiful names for new packages? After refactorings it will be much easier to clean and develop features that are currently provided by zope.app.publisher. For instance I'd like to try to simplify browser resources code somewhat, but it's for another proposal :) -- WBR, Dan Korostelev

8 23

zc.relationship - can't pickle module objects
by Martin Aspeli 09 Nov '09

09 Nov '09

Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? zc.relationship.index.Index's initialiser: def __init__(self, attrs, defaultTransitiveQueriesFactory=None, dumpRel=generateToken, loadRel=resolveToken, relFamily=IFBTree, deactivateSets=False): self._name_TO_mapping = OOBTree.OOBTree() # held mappings are objtoken to (relcount, relset) self._EMPTY_name_TO_relcount_relset = OOBTree.OOBTree() self._reltoken_name_TO_objtokenset = OOBTree.OOBTree() self.defaultTransitiveQueriesFactory = defaultTransitiveQueriesFactory self._relTools = getModuleTools(relFamily) self._relTools['load'] = loadRel self._relTools['dump'] = dumpRel self._relLength = Length.Length() self._relTokens = self._relTools['TreeSet']() self.deactivateSets = deactivateSets self._attrs = _attrs = {} # this is private, and it's not expected to # mutate after this initial setting. seen = set() for data in attrs: # see README.txt for description of attrs. if zope.interface.interfaces.IElement.providedBy(data): data = {'element': data} res = getModuleTools(data.get('btree', IFBTree)) res['element'] = val = data['element'] res['attrname'] = val.__name__ res['name'] = data.get('name', res['attrname']) if res['name'] in _attrs or val in seen: raise ValueError('Duplicate in attrs', name, val) seen.add(val) _attrs[res['name']] = res res['dump'] = data.get('dump', generateToken) res['load'] = data.get('load', resolveToken) if (res['dump'] is None) ^ (res['load'] is None): raise ValueError( "either both of 'dump' and 'load' must be None, or neither") # when both load and dump are None, this is a small # optimization that can be a large optimization if the returned # value is one of the main four options of the selected btree # family (BTree, TreeSet, Set, Bucket). res['interface'] = val.interface res['multiple'] = data.get('multiple', False) res['call'] = zope.interface.interfaces.IMethod.providedBy(val) if res['TreeSet'].__name__.startswith('I'): Mapping = IOBTree.IOBTree else: assert res['TreeSet'].__name__.startswith('O') Mapping = OOBTree.OOBTree self._name_TO_mapping[res['name']] = Mapping() # these are objtoken to (relcount, relset) Regards, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

3 15

Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
by yuppie 27 Oct '09

27 Oct '09

Hi! SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path. So this no longer works in zopectl: ZDCTL="$SOFTWARE_HOME/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" Therefore mkzopeinstance now creates something like this: ZDCTL="/path/to/eggs/Zope2-2.12.0b3-py2.5-linux-i686.egg/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" Problem: -------- - the code in mkzopeinstance.py that looks up the Zope2 path fails on some platforms - if the software is updated, you have to change the paths in runzope and zopectl of each instance Solution: --------- 1.) Add two new entry points in setup.py: runzope=Zope2.Startup.run:run zopectl=Zope2.Startup.zopectl:run If the software is installed, executable runzope and zopectl files are created in the bin directory. That should work with zc.buildout and with easy_install. 2.) Modify the runzope and zopectl files created by mkzopeinstance: The result should look like this: ZDCTL="/path/to/install/bin/zopectl" exec "$ZDCTL" -C "$CONFIG_FILE" "$@" mkzopeinstance would make the assumption that executable runzope and zopectl files exist in the same directory as mkzopeinstance itself. Risks: ------ - mkzopeinstance has a --python option. The specified Python interpreter will no longer be used to execute runzope or zopectl. - uses cases might exist that no longer work after that change Any thoughts? Is the 2.12 branch still open for changes like that? Cheers, Yuppie

7 22

Subversion externals versus mirroring
by Christian Theune 06 Oct '09

06 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, a long-standing issue with our mirror of svn.zope.org are the absolute URLs of externals: they require the repository to be available on a given URL. I propose to use relative URLs for externals. I guess a complete update isn't necessary, but I'd like to improve the situation and start using them from now on. Maybe we should also put a commit hook in place as a safety belt? However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher. As a side effect this will also make svn/svn+ssh work in a nicer way (IMHO) as the externals will follow the protocol of what you used for checkout. Christian - -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnoB8ACgkQdUt9X/gknwI9lgCcDjO320EGllkcaJT8rA7aR+pa rVIAn2Qh5D7sIGMmNPSyClx72PHBhL80 =5696 -----END PGP SIGNATURE-----

18 31

ploneconf2009
by Adam GROSZER 01 Oct '09

01 Oct '09

Hello, Anyone coming? (And ZTK sprinting?) -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: There is a difficulty about disagreeing with God. He is the source from which all your reasoning power comes: you could not be right and He wrong any more than a stream can rise higher than its own source... you are arguing against the very power that makes you able to argue at all. - C.S. Lewis

3 3

zope.filerepresentation
by Martin Aspeli 01 Oct '09

01 Oct '09

Hi, I'm doing some work with WebDAV representations in Zope 2, among other things, and I'm trying to see if we should use zope.filerepresentation as the central abstraction for file read/write operations. However, I find myself lacking a couple of things: 1) A way for an IReadFile to return the file's MIME (content) type (for the Content-Type, for example) and an optional filename (for the Conent-Disposition header, for example) 2) A way for an IWriteFile to be told about the MIME type and encoding of the data it is consuming. I know that IFileFactory() contains this, but data is not always going to be written to a new file, so setting this from the factory won't work. 3) I see this comment: # TODO: We will add ILargeReadFile and ILargeWriteFile to efficiently # handle large data. But it seems this was never implemented. I need a way for the IWriteFile.write() to be passed a file-like object (in fact, there's not really any clear notion of what the 'data' parameter is, but I assume it's meant to be a str object), and for IReadFile.read() to return a file stream iterator of some kind instead of the full raw data. I see two options here: - add a new plone.filerepresentation that extends these interfaces - commit some changes to zope.filerepresentation and make a new release of this Since zope.filerepresentation is really *just* interfaces, #2 seems best. Any objections? Here's an initial take on the interfaces: class IReadFile(Interface): """Provide read access to file data """ def read(): """Return the file data as a str """ def size(): """Return the data length """ class ILargeReadFile(IReadFile): """Provide efficient read access to file data """ def getContentType(): """Get the content/MIME type of the file as a string in the form 'major/minor'. Return None if this is not known. """ def getFilename(): """Get the intended file name for this file. Return None if this is not known. """ def getIterator(): """Return an iterable of the file data """ class IWriteFile(Interface): def write(data): """Update the file data """ class ILargeWriteFile(IWriteFile): def writeFile(data, contentType=None, encoding=None): """Update the file data. data is a file-like object containing input data contentType is the content/MIME type of the data as a string in the form 'major/minor'. It may be None if unknown. encoding is the encoding of the string. It may be None if unknown. """ This should be 100% backwards compatible. The downside is that people will need to implement both write() and writeFile() / read() and getIterator() to support both str based and stream based reading and writing, but that's easily addressed with a StringIO. And of course, nothing in the ZTK will actually use these new interfaces, but that could come later. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book

4 6

zope.catalog in ZTK
by Albertas Agejevas 30 Sep '09

30 Sep '09

Hi all, zope.catalog is a crucial part of ZTK, as it adds the equivalent of RDBMS SELECT queries to our ODB based apps. However in my opinion its default setup is suboptimal as a generic library in ZTK, because it is hardwired up for ZMI "point and click" operation. As soon as you create and register an ICatalog utility, every ObjectAddedEvent and ObjectModifiedEvent will trigger stuffing the object into intids, and each intid registration event will trigger an attempt to index an object. When you add an index to the catalog, it gets reindexed automatically. Because these behaviours are implemented by event handlers, there is no way for an app to override or disable them. There is an "opt out" mechanism for keeping objects out of the catalog (INoAutoIndex, INoAutoReindex marker interfaces), but curiously the latter does not inherit from the former,so your object can be indexed on modification even if you made it provide INoAutoIndex. Automatically stuffing all newly added objects into the int ids utility and then further into the catalog is bad, because, first, it cripples any alternative uses of the int ids utility, turns it into purely a catalog accessory, and second, places some restrictions on containers and contained objects due to the persistent oid based key reference implementation. About a year ago zope.app.catalog as been moved to zope.catalog. I think during this move there was a unique opportunity to leave these event handlers behind in zope.app.catalog, so that the "no .app" version is free of these forced choices. But perhaps it's not too late to do in now? After all, no stable version of Zope 3 / ZTK codebase has been released after this move? People relying on automatic indexing would have to register a couple of event handlers in their configurations (or include zope.app.catalog), but the rest of us would be able to choose the policy of how and when the objects are registered with IntIds and indexed in the catalog. Albertas -- http://www.pov.lt/ -- Zope and Python consulting

5 7

Zope Tests: 8 OK
by Zope Tests Summarizer 30 Sep '09

30 Sep '09

Summary of messages to the zope-tests list. Period Tue Sep 29 12:00:00 2009 UTC to Wed Sep 30 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 Sep 29 20:44:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012664.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Sep 29 20:46:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012665.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Tue Sep 29 20:48:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012666.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue Sep 29 20:50:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012667.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Tue Sep 29 20:52:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012668.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Tue Sep 29 20:54:15 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012669.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Tue Sep 29 20:56:15 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012670.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Tue Sep 29 20:58:15 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-September/012671.html

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev September 2009