October 2009 - Zope-Dev

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

Testrunner option for running tests in random order?!?
by Christian Theune 23 Dec '09

23 Dec '09

Hi, I *thought* the test runner had a feature to run tests in randomized order, but I can't find it. Is that something that Zope 2 had and that was never ported to zope.testing? I couldn't find in the history either. /me is confused. -- 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

5 15

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

Where does ISite belong conceptually?
by Thomas Lotze 04 Nov '09

04 Nov '09

While writing tests for the zope.site.hooks module I'm moving to zope.component, I notice that the module calls getSiteManager() on an site object. Such an object isn't technically required to implement an interface that declares that method, but there is one, or rather a pair of them: IPossibleSite and ISite. These interfaces are currently defined by zope.location even though they aren't involved with the concept of location at all. As these two interfaces have the same concept of a site that zope.component has (i.e. simply an object that has a component registry associated with it), I propose moving IPossibleSite and ISite to zope.component, leaving BBB imports behind. Any objections? -- Thomas

5 7

CMF/Zope3-ZTK Microsites
by Andreas Jung 03 Nov '09

03 Nov '09

Hi there, I am currently working on the plan for the www.zope.org relaunch. Rough ideas are documented here: http://www.coactivate.org/projects/wwwzopeorg-relaunch/project-home Regarding the Zope3/ZTK and CMF subprojects: what are the plans of those subjects for moving to dedicated microsites. We have basically two options: - microsites based on Sphinx - something based on Plone >From the look & feel point of view there are basically two options: a) use the current zope2.zope.org design b) use the upcoming www.zope.org design (undecided right now) Please let me know in order to incorporate yours ideas and plans with the www.zope.org relaunch master plan. Andreas -- ZOPYX Ltd. & Co KG \ ZOPYX & Friends Charlottenstr. 37/1 \ The experts for your Python, Zope and D-72070 Tübingen \ Plone projects www.zopyx.com, info(a)zopyx.com \ www.zopyx.de/friends, friends(a)zopyx.de ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting

3 4

Zope Tests: 6 OK, 2 Failed
by Zope Tests Summarizer 03 Nov '09

03 Nov '09

Summary of messages to the zope-tests list. Period Fri Oct 30 13:00:00 2009 UTC to Sat Oct 31 13:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Test failures ------------- Subject: FAILED (failures=1) : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Fri Oct 30 21:52:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012923.html Subject: FAILED (failures=1) : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Fri Oct 30 21:56:07 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012925.html Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Fri Oct 30 21:46:05 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012920.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri Oct 30 21:48:05 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012921.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Fri Oct 30 21:50:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012922.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Fri Oct 30 21:54:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012924.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Fri Oct 30 21:58:07 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012926.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Fri Oct 30 22:00:07 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012927.html

7 6

proposal: Custom schema properties
by Adam GROSZER 01 Nov '09

01 Nov '09

Hello, Custom schema properties proposal ================================= The problem ------------ is that we have a "baseline" project. This baseline project gets customized for each client. Each client has different (usually just a little bit) needs in terms of field titles and field required. The real problem is, to achieve this we have to create a new interface with the overridden field. This starts the domino effect, we have to create a new class, this new class needs to be instantiated, new add form, new edit form and register those. A hell lot of code to support that tiny change. The solution ------------ would be to have default schema properties defined as "usual" (depending on the implementation the field object would come from a different package). Those defaults can be overridden by "Interface.fieldName" and site (by utility or adapter lookup). Seems like fields that are not overridden in the interface subclasses might not be overridden. Further goal could be to have these customizations easily modified TTW. That somehow suggest that an adapter registration for each property customization is a no-go. Performance Performance needs to be as close as possible to the plain schema implementation. I guess field properties get evaluated quite often per request, an adapter/utility lookup per property evaluation is a no-go. I'd say zope.schema classes should stay as they are, the custom schema will be done using subclasses. Dependencies If no additional dependencies will be added to zope.schema the implementation could go into zope.schema.custom if yes z3c.schema.custom could be the place. Opinions? Anyone suffering the same problems? Up to now this is just a draft, more checking and tinkering to be done at the ploneconf2009-ZTK sprint. -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: They just buzzed and buzzed.....buzzed.

5 4

zope3 shutdown isn't a proper shutdown?
by Adam GROSZER 31 Oct '09

31 Oct '09

Hello, I have the bad feeling (still need to investigate further) that when running zope3 with WSGI and paster the shutdown is not a proper shutdown but a real hard kill/terminate process. On win32 and *nix too. I remember vaguely that with zserver it wasn't like this. That means e.g. the FileStorage index is not written -- that means it has to be redone on each startup, what costs time. Or transactions killed in the middle of doing something. Anyone out there noticed the same? Even better question: how to nicely stop a WSGI/paster Z3 server (without ZMI ServerControl) -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Positive attitude makes all the difference in the world

2 1