- Zope-Dev - Zope lists

zope.formlib - Overriding default widget attributes
by Alex Leach 12 Apr '12

12 Apr '12

Dear Zope Devs, I'm trying to remove a couple of default attributes from the rendered version of the schema.Text widget, namely cols and rows. I tried overriding the widgets attributes with None, which didn't work. I then found in renderTag, in zope.formlib-4.0.6-py2.7.egg/zope/formlib/widget.py:603 that if a value of one of the keyword arguments (**kw) is set to None, then the value is set to the key, and a deprecation warning is issued. In my case, this therefore produces HTML with attributes like cols="cols", and rows="rows". I don't like that at all, as all my styles are defined in CSS and jQuery, and this overrides them! So, please can this be replaced with a `continue` flow statement instead?? Suggested patch:- zope.formlib-4.0.6-py2.7.egg/formlib> diff widget.py widget.py.orig 600c600,602 < for key, value in sorted(kw.items()): --- > items = kw.items() > items.sort() > for key, value in items: 602c604,611 < continue --- > warnings.warn( > "None was passed for attribute %r. Passing None " > "as attribute values to renderTag is deprecated. " > "Passing None as an attribute value will be disallowed " > "starting in Zope 3.3." > % key, > DeprecationWarning, stacklevel=2) > value = key In fact, I'd also get rid of the `if kw:` line, as it seems unnecessary... Cheers, Alex ps. Sorry if this is a duplicate. I think my original message got rejected as I hadn't subscribed... -- Alex Leach Department of Biology University of York York YO10 5DD United Kingdom www: http://bioltfws1.york.ac.uk/~albl500 EMAIL DISCLAIMER: http://www.york.ac.uk/docs/disclaimer/email.htm -- Alex Leach BSc. MRes. Department of Biology University of York York YO10 5DD United Kingdom www: http://bioltfws1.york.ac.uk/~albl500 EMAIL DISCLAIMER: http://www.york.ac.uk/docs/disclaimer/email.htm

1 0

zope-tests - OK: 40
by Zope tests summarizer 12 Apr '12

12 Apr '12

This is the summary for test reports received on the zope-tests list between 2012-04-10 00:00:00 UTC and 2012-04-11 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results --------------

1 0

Re: [Zope-dev] experimental.broken - Graceful handling of broken interfaces and components in the ZODB
by Ross Patterson 11 Apr '12

11 Apr '12

I've done some more work on this and I've gotten the component registrations fully working now with one exception that I'm having real trouble with. I'd like some help with that, more below. I'm also a bit more clear on what might be appropriate to bring back into zope.interface and I'd like feedback on that. Currently interfaces are pickled as globals. Given their centrality in any ZCA application, I think they should be pickled using a function: def __reduce__(self): return (find_interface, (modulename, globalname)) where find_interface, if ZODB.broken.find_global can be imported, in turn calls: ZODB.broken.find_global(modulename, globalname, Broken=IBroken, type=InterfaceClass) since find_global already has nicely abstracted graceful missing global handling. If this were added to zope.interface, and changed ZODB objects with marker interfaces or persistent registries where all the code for the interfaces is still available will then be updated with pickles that will gracefully handle missing interfaces in the future. Thus you could use zodbupdate to make sure that the interfaces in your ZODB will fail gracefully in the future. Do you agree/disagree that this belongs in zope.interface? What this will not address are existing interfaces-as-globals pickles where the original interface is now missing. That's where the other patches in experimental.broken come in, they intercept the two contexts where we can infer that a missing global should be an interface: instance provides declarations and persistent component registries. By hooking into the unpickling of those objects, we can replace broken classes with broken interfaces as appropriate for those structures. With these patches installed it should be possible to use applications with missing interfaces and to use zodbupdate to make sure that even *already missing* interfaces will fail gracefully both now and in the future. I think these patches don't belong in zope.interface/component and if they work I would likely move them to five.localsitemanager along with a ZCML file that is not loaded by default. Does that sound right? Then one thing I haven't been able to get working is making it possible to commit a changed persistent registry when it includes a component registration for a non-persistent component whose class/type is missing. This works just fine for a *persistent* component whose class/type is missing but fails for a non-persistent component. The error is: AttributeError: 'Bar' object has no attribute '__Broken_newargs__' More specifically, '__Broken_newargs__' is set by the Broken.__new__ method and I've confirmed that this isn't being called by instrumenting __new__, __init__, and __setstate__. Only __setstate__ is called when unpickling the non-persistent broken component not __new__ as should be. Below is the full traceback. I've also left the package repo in the broken state if you want to examine it, the egg checkout is also a buildout: https://github.com/rpatterson/experimental.broken/commit/a4b648dc78e53c7303… Any help with this last issue would be appreciated. Ross Ross Patterson <me(a)rpatterson.net> writes: > Please take a look at experimental.broken: > > https://github.com/rpatterson/experimental.broken > http://pypi.python.org/pypi/experimental.broken > > The handling of broken objects by the ZODB can make an application with > add-ons that use zope.interface far too fragile. If marker interfaces > from an add-on are used on objects in the ZODB, removing that add-on can > make any zope.interface operation on that object fail. Even worse, if > an add-on registers any components in a registry in the ZODB, that > entire registry will become unusable for any ZCA operations which pretty > much breaks everything, including admin interfaces. > > Since the interfaces and the ZCA are often core parts of an application > using the ZODB, it may be appropriate to add special handling for broken > objects to those services. The experimental.broken patches are my > attempt to prototype such special handling. > > For objects in the ZODB which directly provide a marker interface, > these patches allow that object to behave as without the application > of the marker interface if the interface is no longer available. If > the interface is made available again, the full behavior of that > interface is restored. Similarly, if a component whose class, > provided interface, or required interfaces are missing, these patches > allow the registry to perform lookups it would have been able to do > without the broken component registration. If the component > class, provided interface, and required interfaces are restored, > then the component registration is fully restored. > > If an object or registry in the ZODB is committed to the ZODB with > broken interfaces or components, the commit will succeed and it is still > possible to fully restore previous behavior if the missing classes and > interfaces are restored. Unfortunately, because interfaces are pickled > as globals, there's no good way to have the same pickle written on > commit for the interface as was in the original pickle, but it should > behave exactly the same. > > The intention of this package is to see if the implementation of broken > object handling is correct and robust enough to merge into > zope.interface and zope.component themselves. Is this the right > approach? If not why and what would be better? How might this approach > be improved? > > Ross > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1

7 10

Sanity Check on zope.sessions and Zope 2.12.x
by Jeff Rush 11 Apr '12

11 Apr '12

I'm chasing a problem when trying to use zope.sessions with Zope 2.12.x, and I'm beginning to think that they are an incompatible mix of Zope2 and Zope3 technologies. Can anyone confirm either way, so I know whether I'm wasting my time. What is happening is when I adapt the request I receive to IClientId, the CookieClientIdManager within zope.sessions code (logically) wants to invoke request.response.getCookie(). However the response object my view is receiving is a ZServerHTTPResponse, which lacks such a method. Considering that Zope 2.12.x runs ZServer, it makes sense I'm seeing ZServerHTTPRequest/ZServerHTTPResponse objects, but that means the ClientIdManager inside zope.session is just not compatible with ZServer. Am I missing something? Is there some magic someplace that fixes up the incompatibility in some way I'm missing? I'm guessing my only solution is to re-implement a ClientIdManager utility that restricts itself to the API provided by ZServerHTTPRequest/ZServerHTTPResponse. -Jeff

2 1

zope-tests - OK: 40
by Zope tests summarizer 11 Apr '12

11 Apr '12

This is the summary for test reports received on the zope-tests list between 2012-04-09 00:00:00 UTC and 2012-04-10 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results --------------

1 0

zope-tests - OK: 40
by Zope tests summarizer 10 Apr '12

10 Apr '12

This is the summary for test reports received on the zope-tests list between 2012-04-08 00:00:00 UTC and 2012-04-09 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results --------------

1 0

zope-tests - FAILED: 5, OK: 40
by Zope tests summarizer 09 Apr '12

09 Apr '12

This is the summary for test reports received on the zope-tests list between 2012-04-07 00:00:00 UTC and 2012-04-08 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux [1] Repository policy check found errors in 307 projects [2] Total languishing bugs for zope2: 10 [3] Total languishing bugs for zope: 75 [4] Total languishing bugs for zopeapp: 1 [5] Total languishing bugs for zopetoolkit: 210 ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -------------- [1] FAILED Repository policy check found errors in 307 projects https://mail.zope.org/pipermail/zope-tests/2012-April/060317.html [2] FAILED Total languishing bugs for zope2: 10 https://mail.zope.org/pipermail/zope-tests/2012-April/060315.html [3] FAILED Total languishing bugs for zope: 75 https://mail.zope.org/pipermail/zope-tests/2012-April/060314.html [4] FAILED Total languishing bugs for zopeapp: 1 https://mail.zope.org/pipermail/zope-tests/2012-April/060312.html [5] FAILED Total languishing bugs for zopetoolkit: 210 https://mail.zope.org/pipermail/zope-tests/2012-April/060313.html

1 0

Re: [Zope-dev] [Plone-developers] experimental.broken - Graceful handling of broken interfaces and components in the ZODB
by Malthe Borch 08 Apr '12

08 Apr '12

On 7 November 2011 09:17, Ross Patterson <me(a)rpatterson.net> wrote: > The intention of this package is to see if the implementation of broken > object handling is correct and robust enough to merge into > zope.interface and zope.component themselves. Is this the right > approach? If not why and what would be better? How might this approach > be improved? (removed plone-dev from cc). Isn't it symptom treatment though? If you've got an add-on which adds marker interfaces to "general objects", shouldn't that add-on remove – or no longer provide – those same interfaces when it's uninstalled? At least in Plone, you can easily query content objects providing a particular set of interfaces. I think it's a non-goal to be able to run a system without all the required software – which is how I understand it when you just do a "hard remove" of an add-on without a prior "soft remove". \malthe

3 2

zope-tests - OK: 40
by Zope tests summarizer 08 Apr '12

08 Apr '12

This is the summary for test reports received on the zope-tests list between 2012-04-06 00:00:00 UTC and 2012-04-07 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results --------------

1 0

zope-tests - OK: 40
by Zope tests summarizer 07 Apr '12

07 Apr '12

This is the summary for test reports received on the zope-tests list between 2012-04-05 00:00:00 UTC and 2012-04-06 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results --------------

1 0