June 2006 - Zope-Dev

Database mounting problem in 2.9.3?
by Chris Withers 26 Jun '06

26 Jun '06

Hi All, Get this error on startup with one project I've just moved to Zope 2.9.3: File "/usr/local/zope/2.9.3/lib/python/Zope2/Startup/datatypes.py", line 175, in createDB return ZODBDatabase.open(self, databases) File "/usr/local/zope/2.9.3/lib/python/ZODB/config.py", line 105, in open databases=databases) File "/usr/local/zope/2.9.3/lib/python/ZODB/DB.py", line 262, in __init__ raise ValueError("database_name %r already in databases" % ValueError: database_name 'packed' already in databases I still seem to be able to access stuff in this database just fine so I don't know what's going on... Any ideas greatfully received... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

2 3

Re: SVN: Zope/branches/tseaver-retire_zpkg/ Note dropping of 'zpkg'; use a current version number.
by Philipp von Weitershausen 24 Jun '06

24 Jun '06

Tres Seaver wrote: > Log message for revision 68810: > Note dropping of 'zpkg'; use a current version number. > > Changed: > U Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt > U Zope/branches/tseaver-retire_zpkg/setup.py > > -=- > Modified: Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt > =================================================================== > --- Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt 2006-06-23 23:30:41 UTC (rev 68809) > +++ Zope/branches/tseaver-retire_zpkg/doc/CHANGES.txt 2006-06-24 03:03:22 UTC (rev 68810) > @@ -18,6 +18,9 @@ > > Bugs fixed > > + - Returned to the "classic" './configure && make && make install' > + recipe, dropping the use of 'zpkg' for building Zope2 releases. I don't think this is a bugfix :) > + > - OFS Application: Updated deprecation warnings. > Support for '__ac_permissions__' and 'meta_types' will be removed in > Zope 2.11, 'methods' support might remain longer. > > Modified: Zope/branches/tseaver-retire_zpkg/setup.py > =================================================================== > --- Zope/branches/tseaver-retire_zpkg/setup.py 2006-06-23 23:30:41 UTC (rev 68809) > +++ Zope/branches/tseaver-retire_zpkg/setup.py 2006-06-24 03:03:22 UTC (rev 68810) > @@ -34,6 +34,7 @@ > --install-platlib=/usr/local/lib/zope \ > --install-purelib=/usr/local/lib/zope > """ > +ZOPE_VERSION = '2.9.4-alpha' Since you're denoting this as a "current version number", do I take it that you're planning on changing the way Zope 2.9 and 2.10 releases are created as well? I would consider egg-based deployment a feature; at least it's a big enough change that I'd be worried for it to occur in a maintenance release. After all, zpkg *does* work and the way zpkg-based releases are installed *is* documented (hence protest against this being a bugfix). It just gives some people headaches (which is why I'm +1 to the overall idea). Philipp

2 2

buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
by buildbot＠zope.com 24 Jun '06

24 Jun '06

The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6317 Blamelist: andreasjung,benji_york,ctheune,dominikhuber,hdima,jens,philikon,tseaver,yuppie BUILD FAILED: failed test sincerely, -The Buildbot

1 0

Re: default view
by Florent Guillaume 22 Jun '06

22 Jun '06

Florent Guillaume wrote: > So here's a proposal: how about having the following order: > - __bobo_traverse__ > - unacquired attribute > - zope 3 views > - acquired attributes Attached is the current diff I'm working with (for Zope 2.10). Please review the unit test (which pass as is), to check if you agree with the semantics. I've decided that if you traverse ".../foo/@@something", then only the zope 3 views will be consulted and never an attribute. I hope everyone agrees with that. The remaining important question is: if a *default* view is specified using the zope 3 mechanism, should we always treat it as a zope 3 view, and refuse to lookup an attribute with that name? Currently the traverse code is not completely coherent with respect to that, there's a NotFound in the tests I added which isn't coherent with the rest. So we should decide on one semantic. To explicit the question, if you have: <browser:defaultView name="myview" for=".IFoo"/> and the publisher decides it has to use the default view (when ".../foo/" is traversed), should it try to lookup "myview" as an attribute? Or should only the zope 3 view be looked up? I'd be inclined to not use attributes, after all that's zope 3 directives we're talking about. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com Index: lib/python/ZPublisher/tests/testBaseRequest.py =================================================================== --- lib/python/ZPublisher/tests/testBaseRequest.py (revision 68718) +++ lib/python/ZPublisher/tests/testBaseRequest.py (working copy) @@ -3,8 +3,15 @@ from Acquisition import Implicit from ZPublisher.BaseRequest import BaseRequest from ZPublisher.HTTPResponse import HTTPResponse +from ZPublisher import NotFound +import zope.interface +import zope.testing.cleanup +import zope.traversing.namespace +from zope.app.testing import ztapi +from zope.publisher.interfaces.browser import IDefaultBrowserLayer + class DummyObjectBasic(Implicit): """Dummy class with docstring.""" @@ -166,7 +173,6 @@ def test_traverse_withBDEmpty(self): # Collector 1079 (infinite loop 2) - from ZPublisher import NotFound r = self.makeBaseRequest() self.f1.objWithBD._default_path = [''] self.failUnlessRaises(NotFound, r.traverse, 'folder/objWithBD') @@ -174,7 +180,6 @@ def test_traverse_withBBT_handles_AttributeError(self): # Test that if __bobo_traverse__ raises AttributeError # that we get a NotFound - from ZPublisher import NotFound r = self.makeBaseRequest() self.failUnlessRaises(NotFound, r.traverse, 'folder/objWithBBT/bbt_foo') @@ -194,7 +199,6 @@ # and __bobo_traverse__ # __bobo_traverse__ should raise an AttributeError, which will # raise a NotFound - from ZPublisher import NotFound r = self.makeBaseRequest() self.f1.objWithBDBBT._default_path = ['xxx'] r = self.makeBaseRequest() @@ -214,27 +218,22 @@ self.assertEqual(r.response.base, '') def test_traverse_attribute_without_docstring(self): - from ZPublisher import NotFound r = self.makeBaseRequest() self.assertRaises(NotFound, r.traverse, 'folder/objBasic/noview') def test_traverse_class_without_docstring(self): - from ZPublisher import NotFound r = self.makeBaseRequest() self.assertRaises(NotFound, r.traverse, 'folder/objWithoutDocstring') def test_traverse_attribute_of_class_without_docstring(self): - from ZPublisher import NotFound r = self.makeBaseRequest() self.assertRaises(NotFound, r.traverse, 'folder/objWithoutDocstring/view') def test_traverse_attribute_and_class_without_docstring(self): - from ZPublisher import NotFound r = self.makeBaseRequest() self.assertRaises(NotFound, r.traverse, 'folder/objWithoutDocstring/noview') def test_traverse_simple_type(self): - from ZPublisher import NotFound r = self.makeBaseRequest() self.assertRaises(NotFound, r.traverse, 'folder/simpleString') self.assertRaises(NotFound, r.traverse, 'folder/simpleList') @@ -242,14 +241,144 @@ self.assertRaises(NotFound, r.traverse, 'folder/simpleComplex') def test_traverse_set_type(self): - from ZPublisher import NotFound r = self.makeBaseRequest() self.assertRaises(NotFound, r.traverse, 'folder/simpleSet') self.assertRaises(NotFound, r.traverse, 'folder/simpleFrozenSet') +class IDummy(zope.interface.Interface): + """IDummy""" + +class DummyObjectBasicZ3(DummyObjectBasic): + zope.interface.implements(IDummy) + def __init__(self, name): + self.name = name + +class DummyObjectBasicZ3WithAttr(DummyObjectBasicZ3): + def meth(self): + """doc""" + return 'meth on %s' % self.name + def methonly(self): + """doc""" + return 'methonly on %s' % self.name + +class DummyView(Implicit): + def __init__(self, content, request): + self.content = content + self.request = request + def __call__(self): + return 'view on %s' % (self.content.name) + +class TestBaseRequestZope3Views(TestCase): + + def setUp(self): + zope.testing.cleanup.cleanUp() + self.root = DummyObjectBasic() + self.f1 = self.root._setObject('folder', DummyObjectBasicZ3('folder')) + self.f1._setObject('obj', DummyObjectBasicZ3('obj')) + self.f1._setObject('withattr', DummyObjectBasicZ3WithAttr('withattr')) + self.f2 = self.root._setObject('folder2', + DummyObjectBasicZ3WithAttr('folder2')) + self.f2._setObject('obj2', DummyObjectBasicZ3('obj2')) + self.f2._setObject('withattr2', DummyObjectBasicZ3WithAttr('withattr2')) + + # This is needed to make "zope 3" traversing work + zope.interface.classImplements(BaseRequest, IDefaultBrowserLayer) + + # Define our 'meth' view + ztapi.browserView(IDummy, 'meth', DummyView) + + # Bind @@ to the view namespace + ztapi.provideNamespaceHandler('view', zope.traversing.namespace.view) + + def tearDown(self): + zope.testing.cleanup.cleanUp() + + def makeBaseRequest(self): + response = HTTPResponse() + environment = { 'URL': '', + 'PARENTS': [self.root], + 'steps': [], + '_hacked_path': 0, + '_test_counter': 0, + 'response': response } + return BaseRequest(environment) + + def test_traverse_view(self): + """simple view""" + r = self.makeBaseRequest() + ob = r.traverse('folder/obj/meth') + self.assertEqual(ob(), 'view on obj') + ob = r.traverse('folder/obj/@@meth') + self.assertEqual(ob(), 'view on obj') + # using default view + ztapi.setDefaultViewName(IDummy, 'meth') + ob = r.traverse('folder/obj/') + self.assertEqual(ob(), 'view on obj') + ob = r.traverse('folder/obj') + self.assertEqual(ob(), 'view on obj') + + def test_traverse_view_attr_local(self): + """method on object used first""" + r = self.makeBaseRequest() + ob = r.traverse('folder/withattr/meth') + self.assertEqual(ob(), 'meth on withattr') + ob = r.traverse('folder/withattr/@@meth') + self.assertEqual(ob(), 'view on withattr') + # using default view + ztapi.setDefaultViewName(IDummy, 'meth') + ob = r.traverse('folder/withattr/') + self.assertEqual(ob(), 'meth on withattr') + ob = r.traverse('folder/withattr') + self.assertEqual(ob(), 'meth on withattr') + + def test_traverse_view_attr_above(self): + """view takes precedence over acquired attribute""" + r = self.makeBaseRequest() + ob = r.traverse('folder2/obj2/meth') + self.assertEqual(ob(), 'view on obj2') # used to be buggy (acquired) + ob = r.traverse('folder2/obj2/@@meth') + self.assertEqual(ob(), 'view on obj2') + # using default view + ztapi.setDefaultViewName(IDummy, 'meth') + ob = r.traverse('folder2/obj2/') + self.assertEqual(ob(), 'view on obj2') + ob = r.traverse('folder2/obj2') + self.assertEqual(ob(), 'view on obj2') + + def test_traverse_view_attr_local2(self): + """method with other method above""" + r = self.makeBaseRequest() + ob = r.traverse('folder2/withattr2/meth') + self.assertEqual(ob(), 'meth on withattr2') + ob = r.traverse('folder2/withattr2/@@meth') + self.assertEqual(ob(), 'view on withattr2') + # using default view + ztapi.setDefaultViewName(IDummy, 'meth') + ob = r.traverse('folder2/withattr2/') + self.assertEqual(ob(), 'meth on withattr2') + ob = r.traverse('folder2/withattr2') + self.assertEqual(ob(), 'meth on withattr2') + + def test_traverse_view_attr_acquired(self): + """normal acquired attribute without view""" + r = self.makeBaseRequest() + ob = r.traverse('folder2/obj2/methonly') + self.assertEqual(ob(), 'methonly on folder2') + self.assertRaises(NotFound, r.traverse, 'folder2/obj2/@@methonly') + # using default view + ztapi.setDefaultViewName(IDummy, 'methonly') + ob = r.traverse('folder2/obj2/') + self.assertEqual(ob(), 'methonly on folder2') + ob = r.traverse('folder2/obj2') + self.assertEqual(ob(), 'methonly on folder2') + + def test_suite(): - return TestSuite( ( makeSuite(TestBaseRequest), ) ) + return TestSuite(( + makeSuite(TestBaseRequest), + makeSuite(TestBaseRequestZope3Views), + )) if __name__ == '__main__': main(defaultTest='test_suite') Index: lib/python/ZPublisher/BaseRequest.py =================================================================== --- lib/python/ZPublisher/BaseRequest.py (revision 68718) +++ lib/python/ZPublisher/BaseRequest.py (working copy) @@ -17,6 +17,7 @@ from urllib import quote import xmlrpc from zExceptions import Forbidden, Unauthorized, NotFound +from Acquisition import aq_base from zope.interface import implements, providedBy, Interface from zope.component import queryMultiAdapter @@ -72,6 +73,7 @@ raise Forbidden("Object name begins with an underscore at: %s" % URL) try: + # 1. Try __bobo_traverse__ if hasattr(object,'__bobo_traverse__'): subobject=object.__bobo_traverse__(request, name) if type(subobject) is type(()) and len(subobject) > 1: @@ -81,24 +83,28 @@ object, subobject = subobject[-2:] else: try: + # 2. Try as attribute on base object + getattr(aq_base(object), name) subobject=getattr(object, name) except AttributeError: + # 2.5 Try as item subobject=object[name] - + except (AttributeError, KeyError, NotFound): - # Find a view even if it doesn't start with @@, but only - # If nothing else could be found + # 4. Try as view subobject = queryMultiAdapter((object, request), Interface, name) if subobject is not None: # OFS.Application.__bobo_traverse__ calls # REQUEST.RESPONSE.notFoundError which sets the HTTP # status code to 404 - request.RESPONSE.setStatus(200) + request.response.setStatus(200) # We don't need to do the docstring security check # for views, so lets skip it and return the object here. return subobject.__of__(object) - raise + # 5. Try as acquired attribute, may raise + subobject = getattr(object, name) + # Ensure that the object has a docstring, or that the parent # object has a pseudo-docstring for the object. Objects that # have an empty or missing docstring are not published.

6 24

Re: [Zope-dev] Proposal: Scrap zpkg for Zope2 releases
by Andreas Jung 22 Jun '06

22 Jun '06

--On 22. Juni 2006 11:01:21 -0400 Fred Drake <fdrake(a)gmail.com> wrote: > On 6/22/06, Tres Seaver <tseaver(a)palladion.com> wrote: >> I believe that the extra flexibility which zpkg is intended to provide >> (dependency-based subset distributions, primarily) would be better >> served by moving Zope to use eggs, and that we should thus retire zpkg >> as the means for building Zope2 releases. Instead, we should recreate >> the version of the 'inst' stuff removed in the 2.9 beta cycle, and >> update it for any changes to the tree made since then. > > +1 +2 from the release manager side. zpkg has always been a mystery to me. Dealing with zpkg issues has always been like driving with 100mph through fog. Andreas

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 21 Jun '06

21 Jun '06

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6267 Blamelist: alecm,benji_york,ctheune,fdrake,hdima,jim,mgedmin,regebro,tseaver BUILD FAILED: failed test sincerely, -The Buildbot

1 0

Nasty error message with obscure bug
by Chris Withers 21 Jun '06

21 Jun '06

Hi All, Got this weird error message: Module TAL.TALInterpreter, line 701, in translate Module Products.PageTemplates.TALES, line 261, in translate Module Products.Five.i18n, line 51, in translate Module Products.PageTemplates.GlobalTranslationService, line 33, in translate TypeError: expected string or buffer ...and eventually tracked it down to this code: <meta name="description" content="blah" i18n:attributes="description"/> The bug, of course, is that the i18:attributes should be content, not description, which doesn't exist. This results in a None msgid, which PTS used to do something (I don't know whether it was sane or not, no errors) with but which raises the rather obscure error above. I don't know if anything should be done here. Obviously it'd be nice if the error message was a bit nicer ("i18:attributes specified attribute 'description', which did not exist on tag 'meta' in /standard_template.pt") but it's a pretty obscure error. If anyone with greater knowledge could implement the above without much pain, that'd be great. In any case, hopefully Google will catch this some time and save the next weary traveller who bumps into it a couple of hours ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

4 8

buildbot failure in Zope trunk 2.4 Windows 2000 zc-bbwin6
by buildbot＠zope.com 19 Jun '06

19 Jun '06

The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000 zc-bbwin6. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6239 Blamelist: regebro BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 19 Jun '06

19 Jun '06

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6239 Blamelist: regebro BUILD FAILED: failed test sincerely, -The Buildbot

1 0

buildbot failure in Zope trunk 2.4 Linux zc-buildbot
by buildbot＠zope.com 17 Jun '06

17 Jun '06

The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6200 Blamelist: jim,shh BUILD FAILED: failed test sincerely, -The Buildbot

1 0