- Zope-Dev - Zope lists

Zope Tests: 5 OK
by Zope Tests Summarizer 20 Jan '08

20 Jan '08

Summary of messages to the zope-tests list. Period Sat Jan 19 12:00:00 2008 UTC to Sun Jan 20 12:00:00 2008 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Jan 19 20:50:47 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008976.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Jan 19 20:52:17 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008977.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 19 20:53:47 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008978.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 19 20:55:17 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008979.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 19 20:56:48 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008980.html

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 19 Jan '08

19 Jan '08

Summary of messages to the zope-tests list. Period Fri Jan 18 12:00:00 2008 UTC to Sat Jan 19 12:00:00 2008 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Jan 18 21:12:40 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008971.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Jan 18 21:14:11 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008972.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 18 21:15:41 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008973.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 18 21:17:11 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008974.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 18 21:18:41 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008975.html

1 0

A z3c.jbot without a monkey
by Malthe Borch 19 Jan '08

19 Jan '08

The z3c.jbot package basically offers an easy way to provide template overrides much like zope 2 skins. It addresses the common issue with using a framework that already provides its own skin; you want to be able to easily customize it. In the current implementation, z3c.jbot monkeys its way into zope.pagetemplate to easily allow overriding the template source file. This is of course not optimal, but it works rather well. However, if we routinely switch between different file sources, performance will certainly suffer. This could happen if for instance a template override was registered only for a certain layer (not currently possible, but certainly desirable). At any rate, this could be fixed at the level of the page template implementation. Getting back to the monkey, perhaps it would make sense to formalize the way a template object gets its source file. The template class could adapt to an ``IFileSource`` implementation that would provide a filename. If there was such an entry point, other template implementations such as z3c.pt could also play along. But perhaps the whole idea is symptom treatment and there's no way forward. Comments welcome, especially in the light of PLIP #216 in which the z3c.jbot approach has been selected for inclusion in Plone*. *) http://plone.org/products/plone/roadmap/216 \malthe

5 7

zope2 webdav memory usage...
by Chris McDonough 18 Jan '08

18 Jan '08

Hi folks, While messing with Zope2's webdav implementation, I ran across this bit of memory-management code: dflag = hasattr(ob, '_p_changed') and (ob._p_changed == None) ... stuff ... if dflag: ob._p_deactivate() I actually think this should be: dflag = not getattr(ob, '_p_changed', None) ... stuff ... if dflag: ob._p_deactivate() .. because when _p_changed on a persistent object (as I read it in the persistence interface file) is None, the object is a ghost. The object will never be a ghost here because non-_p_ attributes are looked up on it before we check for _p_changed, and even if it was a ghost, deactivating a ghost (to turn it into a ghost) is just not useful. I think the only time we don't want to deactivate it is if it has been changed (when _p_changed is True). Or at least that seems to be the intent. Does this sound right? I have a feeling the answer will be crickets, but I figure what the heck. - C

6 13

Zope Tests: 5 OK
by Zope Tests Summarizer 18 Jan '08

18 Jan '08

Summary of messages to the zope-tests list. Period Thu Jan 17 12:00:00 2008 UTC to Fri Jan 18 12:00:00 2008 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 17 21:28:25 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008966.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 17 21:29:56 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008967.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 17 21:31:26 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008968.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 17 21:32:56 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008969.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 17 21:34:26 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008970.html

1 0

Request typing (to get the xmlrpc layer discussion finished)
by Christian Zagrodnick 17 Jan '08

17 Jan '08

Hi, a couple of weeks ago there was some discussion about the skin/layer support for XML-RPC which I implemented without asking (shame on me). As some time has passed now everybody could have some fresh thoughts about it. Let me first summarise: * Skin and layers should be seen as typing the request. * There are no general objections against having layers for XML-RPC. * There are objections against using ++skin++ for XML-RPC, ++api++ would be fine. Discussing the issue here at gocept again we've come to the following: There are different kinds of request (BrowserRequest, XMLRPCRequest, FTPRequest, …) which depend on the “channel” or server zope is accessed through. Then, depending on the kind of request, it often is desirable to further type the request: * a skin for browser requests * an API for xmlrpc requests * maybe different listings or content views for webdav We’d like to codify this understanding (the general concept of marking a request with a type) using a general IRequestType which all specific type implementations (skins, APIs, ...) are derived from. In our view this allows for understandably named implementations for each channel but still provide a common base. Therefore we propose to: * Create in zope.publisher.interfaces: class IRequestType(zope.interface.interfaces.IInterface): pass * Rename IXMLRPCSkinType to IXMLRPCAPIType(IRequestType) and create a traverser ++api++ for IXMLRPCApiType. * Use IRequestType as new base of IBrowserSkinType (instead of IInterface). * Do *not* provide any traverser for IRequestType since the traversers should be close to the “channel” so it is easy to understand what is happening. If the traverser name is too far fetched we end in confusion like with skin for xmlrpc. Regards, -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891

11 32

Zope Tests: 5 OK
by Zope Tests Summarizer 17 Jan '08

17 Jan '08

Summary of messages to the zope-tests list. Period Wed Jan 16 12:00:00 2008 UTC to Thu Jan 17 12:00:00 2008 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Jan 16 21:22:38 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008961.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Wed Jan 16 21:24:08 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008962.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 16 21:25:39 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008963.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 16 21:27:09 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008964.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Wed Jan 16 21:28:39 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008965.html

1 0

wiki.zope.org content licence
by Adam Groszer 17 Jan '08

17 Jan '08

Hello, I don't know a better place for asking this. What is the licence for the content of wiki.zope.org? I don't see there any clearly, but that might be my own issue :-) -- Best regards, Adam Groszer mailto:agroszer@gmail.com -- Quote of the day: Ill gotten gains will be ill spent. - Cicero

2 1

z3c.rml test failures
by Baiju M 16 Jan '08

16 Jan '08

Hi Stephan, I am getting some test failure in z3c.rml trunk. One issue is due to the use of non-existing 'font' tag. I can't find this tag in 'rml.dtd' and reference. (But I can see a single use of 'font' tag in reference, but it is in a different context, I think should should be replaced as described below) All the places where 'font' tag used is as a child of 'title' tag. And 'face' is the only attribute used for the font tag in tests. Now 'title' has a 'fontName' attribute, from the DTD and reference I deduced that tests should use this instead of 'font' tag, is it correct ? There is another issue when I run tests in level 2, this can be solved by using few more arguments to Popen . (see the patch attached) There is one more remaining issue while parsing 'tag-textField.xml' I have given the trace back below, but if I parse this file individually, there is no test failure ! May be this is due to tests are not cleaned up properly. Regards, Baiju M Error in test runTest (z3c.rml.tests.test_rml.tag-textField) Traceback (most recent call last): File "/baiju/usr//lib/python2.4/unittest.py", line 260, in run testMethod() File "/home/baiju/office/z298i/z3c.rml/src/z3c/rml/tests/test_rml.py", line 60, in runTest rml2pdf.go(self._inPath, self._outPath) File "/home/baiju/office/z298i/z3c.rml/src/z3c/rml/rml2pdf.py", line 64, in go doc.process(outputFile) File "/home/baiju/office/z298i/z3c.rml/src/z3c/rml/document.py", line 281, in process self.canvas.save() File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfgen/canvas.py", line 877, in save self._doc.SaveToFile(self._filename, self) File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfdoc.py", line 219, in SaveToFile f.write(self.GetPDFData(canvas)) File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfdoc.py", line 241, in GetPDFData return self.format() File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfdoc.py", line 384, in format IOf = IO.format(self) File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfdoc.py", line 778, in format fcontent = format(content, document, toplevel=1) # yes this is at top level File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfdoc.py", line 95, in format f = element.format(document) File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfform.py", line 175, in format return proxy.format(document) File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfpattern.py", line 54, in format L.append(format(value, document)) File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfdoc.py", line 93, in format return document.Reference(element).format(document) File "/home/baiju/office/z298i/z3c.rml/src/reportlab/pdfbase/pdfdoc.py", line 475, in Reference raise ValueError, "object named but not registered" ValueError: object named but not registered

2 2

[Zope2/Multi-Version-Eggs] Imports behaving strange
by Andreas Jung 16 Jan '08

16 Jan '08

Hi, I have running Zope 2 application using SQLAlchemy 0.3.11/z3c.sqlalchemy 1.0.11 and needs to be migrated to SA 0.4/z3c.sqlalchemy 1.1. For the migration period I installed all four versions as multi-version eggs. For debugging purposes, my lib/python/Zope2/Startup/zopectl.py contains: import pkg_resources pkg_resources.require('sqlalchemy==0.4.2p3') pkg_resources.require('z3c.sqlalchemy==1.1.0') import sqlalchemy print sqlalchemy.__version__ import z3c.sqlalchemy from z3c.sqlalchemy.interfaces import ISQLAlchemyWrapper This works nicely. The correct modules are imported properly. Later during the startup phase while initializing a product called "MedienDB" the related code is doing the following import: from z3c.sqlalchemy.interfaces import ISQLAlchemyWrapper This import fails with portError: 'No module named sqlalchemy.interfaces' > /local/HRS2/Devel/ajung/HaufeCMS/lib/python/mediendb/mediendb.py(19)?() -> from z3c.sqlalchemy.interfaces import ISQLAlchemyWrapper although the same import worked much earlier? Any ideas? As said: this issue only occurs with multi-version eggs. Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info(a)zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting

2 3