[Zope-dev] Re: 2.9.4? reStructuredText support?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: --On 8. Juli 2006 07:45:01 -0400 Jim Fulton <[EMAIL PROTECTED]> wrote: On Jul 8, 2006, at 1:11 AM, Andreas Jung wrote: --On 7. Juli 2006 11:03:06 -0400 Jim Fulton <[EMAIL PROTECTED]> wrote: I think we should do a 2.9.4 release to incorporate the recent hot fix. This is easy for me to say, since I won't be doing it. :) Because this recent fix actually fixed the same problem that the previous hot fix was supposed to fix, I think someone needs to work up some decent tests. This is not a trivial task, bit it is necessary. If no one is willing to do this, I think we need to drop the TTW reStructuredText support from Zope 2, as it is too great a risk. Dropping TTW reST is absolutely not an option. I breaks backward compatibility. Sorry, security trumps backward compatibility. BTW, I suspect that a less violent patch could be created, if anyone wants to champion TTW reStructuedText support in Zope 2. Personally, I'm for dropping it. Tres' patch is looking in fine to me. I don't see a need right now for dropping reST with having file inclusing *removed*. Has anyone written tests for Tres' patch? Apparently no one wrote adequate tests for the last hot fix, which helped put us in this situation. I've written some tests (checked in on the trunk). They test the 'raw' and 'include' directives Great! Maybe we can add a similar set for the 'fmt="restructured-text"' in DTML. @Tres: what is the reason to keep the 'raw' code in docutils? I am in favor to remove it and replace it with a NotImplementedError exception (same as for the the 'include' code). The related tests (for reStructredText and ZReST are commented for now) do except a NotImplementedError for a 'raw' directive. 'raw' can be used to disable ReST processing for a block, even if the ':file:' or ':url:' options aren't set.; I was trying to leave the possibility of that use case. Isn't that leaving the door open for XSS (cross-site scripting) attacks? Allowing arbitrary raw HTML to be input allows javascript in the pages, and therefore cookie stealing. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: 2.9.4? reStructuredText support?
Tres Seaver wrote: Another possible fix would be to patch docutils to make the configuration directive for file inclusion disabled by default; that would allow a trusted module to enable them for a given parse, without exposing the feature for untrusted code. Which should be how upstream docutils should be coded in the first place. That file inclusion is allowed by default is beyond me, when the experience of many other systems like TeX or PostScript show that it's a huge security hole. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Philipp von Weitershausen wrote: Tres Seaver wrote: svn: URL 'svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-retire_zpkg/lib/python/zope/app' doesn't match existing URL 'svn://svn.zope.org/repos/main/Zope3/tags/Zope-3.2.1/src/zope/app' in 'lib/python/zope/app' I may have to munge 'zope/app' manually and check it in to get the merge done. Anybody have another suggestion? When replacing a subversioned directory with an external, you first need to remove the directory and commit it. Then, in a next revision, you add the external. I'm actually going the other direction, but I think I still need two transactions (first remove the external, then create and add tne directory) OK, I have merged the 'tseaver-retire_zpkg_branch' to the 2.9 branch, and the 'tseaver-zpkg_retire-2.10' branch to the 2.10 branch and the trunk. Because of the surgery involved in switching 'lib/python/zope/app' from an svn:external to a "real" directlry, your existing sandboxen may neeed some help in completing an 'svn up' (try removing the app directory, if it barfs there). Note that I did *not* repair the test failure which showed up on the 2.10 branch / trunk while I was in the middle of the merge -- it looks as though it might be related to the traversal changes Florent made today, and the failure is the same on the 2.10 branch / trunk *without* the merge as *with* it. Yep I'll check and fix those asap. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: local namespace optimizations?
[EMAIL PROTECTED] wrote: Florent Guillaume wrote at 2006-7-5 18:56 +0200: Is anyone opposed to me removing the stupid: _getattr = getattr _none = None marker = _marker local namespace """optimizations""" that are found in unrestrictedTraverse? Why do you think they were stupid? I call them stupid because they are micro-optimizations that are drowned in the rest of the traversal code and make things harder to read. _none vs None are exactly the same speed in my tests. _marker vs a global have a 0.05 microsecond difference on my machine _getattr vs getattr too. And if we "localize" those, why not localize aq_base as well, and guarded_getattr and securityManager.validate and nsParse and namespaceLookup... At least the current unrestrictedTraverse() code has grown sufficiently complex that it should be rebenched and re-optimize if needed, but it's already complex enough to not keep cruft in it if it's not justified. Florent They do save time -- although it probably does not dominate the total time. -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] local namespace optimizations?
On 5 Jul 2006, at 19:05, Andreas Jung wrote: --On 5. Juli 2006 18:56:25 +0200 Florent Guillaume <[EMAIL PROTECTED]> wrote: Is anyone opposed to me removing the stupid: _getattr = getattr _none = None marker = _marker local namespace """optimizations""" that are found in unrestrictedTraverse? I am pretty sure that the complete Zope core is still full of those optimizations. Does that mean you're for or against it? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] local namespace optimizations?
Is anyone opposed to me removing the stupid: _getattr = getattr _none = None marker = _marker local namespace """optimizations""" that are found in unrestrictedTraverse? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zasync/xmlrpclib problem
Gary, When zasync is used on something that calls a xmlrpclib method s.foo.bar() (using s = xmlrpclib.ServerProxy(...)) and this xmlrpc call fails, it seems that cleanFailure at some point calls repr (s.foo.bar) and this makes a spurious xmlrpc call (because of the dumb _Method class of xmlrpclib which has a __getattr__ but no __repr__). I had to monkey patch xmlrpclib thus, you could probably include it in zasync: import xmlrpclib def xmlrpc_method_repr(self): return '' % self._Method__name xmlrpclib._Method.__repr__ = xmlrpc_method_repr Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: Zope/branches/2.10/ OFS Image: Image and File now both support simple unicode objects for data (they function the same as strings for data).
Rocky Burt wrote:
On Wed, 2006-28-06 at 14:01 +0200, Andreas Jung wrote:
Has this change been discussed?
I don't agree with it. Unicode strings aren't byte strings. File and
Image should only work with byte strings.
Code dealing with them should always know and assume that they use str.
Anything using unicode with them is broken or has done insufficient
input validation.
I agree. This checkin must be reverted. In fact one raise a ValueError in
case the data is a unicode string.
Alrighty, reverting change. Sorry about the confusion. The more I
think about this the more I agree.
I'll still change the logic to do isinstance(data, str) rather than
type('') == type(data) and I'll also add the explicit check for unicode
and raise a ValueError if found, does this all sound ok?
Excellent, thanks.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: Zope/branches/2.10/ OFS Image: Image and File now both support simple unicode objects for data (they function the same as strings for data).
7 +293,6 @@ verifyClass(WriteLockInterface, Image) - def test_suite(): return unittest.TestSuite(( unittest.makeSuite(FileTests), ___ Checkins mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/checkins -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: Zope/branches/2.9/lib/python/ Replace bulk of uses of 'zLOG' with equivalent Python 'logging' module usage.
Andreas Jung wrote: --On 25. Juni 2006 16:32:04 +0200 "Stefan H. Holek" <[EMAIL PROTECTED]> wrote: This, BTW, breaks CMF 1.5 on Zope 2.9. Not sure I/you should care though ;-) Traceback (most recent call last): File "/home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFActionIcons/__init__.py", line 19, in ? from Products.CMFCore.DirectoryView import registerDirectory File "/home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFCore/__init__.py", line 21, in ? import MembershipTool, WorkflowTool, CatalogTool, DiscussionTool File "/home/stefan/autotest/temp/python24-zope29-cmf15/Products/ CMFCore/CatalogTool.py", line 23, in ? from Products.ZCatalog.ZCatalog import LOG ImportError: cannot import name LOG Tres, you replace all 'LOG' vars with 'logger'. Is there a reason for this replacement? We've been using LOG through out the complete Z2 core..we should remain consistent in some way. Certainly not the whole core, Zope 2.10 has many many uses of logger. Including the ones in Zope 3, and ZODB, which *are* part of Zope 2.10. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases
Tres Seaver wrote:
BTW, a small nit of mine with subversion: can anybody tell me how to
find the revision in which a directory was moved / removed, preferably
via the web interface? Subversion doesn't seem to expose a way to ask
about a name which, like the "man upon the stair" isn't there any more.
Something based on svn log -v, for instance:
svn log -v | awk '/^(r| D}/{print};'
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: default view
On 22 Jun 2006, at 14:43, Tres Seaver wrote:
Philipp von Weitershausen wrote:
Dieter Maurer wrote:
Florent Guillaume wrote at 2006-6-18 02:05 +0200:
...
if hasattr(object,'__bobo_traverse__'):
subobject=object.__bobo_traverse__(request, name)
If you are working on it, then you should implement a
means that "__bobo_traverse__" can tell the caller that
it should use the normal default.
This feature makes lots of "__bobo_traverse__" implementations
much saner. A prominent example is the Archetypes' one.
In our private Zope version, I have used an exception
("UseTraversalDefault") for this purpose.
I think that __bobo_traverse__ can raise AttributeError currently to
indicate that it has failed to look up an attribute and that
traversal
should try other options. Apart from being a more explicit spelling,
what advantage would UseTraversalDefault have?
The contract for '__bobo_traverse__' is actually insane on this point,
becuase it has to serve two "masters":
- In publishing traversal, an AttributeErrror raised from
'__bobo_traverse__' has the semantics you describe.
- In '{un,}restrictedTraverse', an AtttributeError causes the whole
traversal process to abort, returning the 'default' value (if
passed), or raising.
Fixing this incompatibility without breaking applications which may be
unknowingling dependent on it is going to be hard.
Which is one of the reasons why abandoning it and moving on to Zope 3
traversal is the only sane way to proceed :)
Abandon = deprecate, yes :)
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Flood of deprecation warnings...
Chris Withers wrote: Both core zope and Plone spew forth in their default state. Zope 2.10 does? It shouldn't. Please point out the deprecation warnings it sends. Also could we please bury the zLOG-was-only-halfwy-deprecated issue that's been beaten to death? Everybody knows there were spurious warnings from it in some past version. Everybody knows it's now been mea-culpa-ed and fixed. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: default view
On 20 Jun 2006, at 13:23, Martijn Faassen wrote: Philipp von Weitershausen wrote: Florent Guillaume wrote: 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). Hey, cool. You know, the real challenge is backporting this all the way to Five 1.2 to ensure compatibility between the current stable Zope 2 releases. We've actually noticed Five 1.2.4 is not compatible with Five 1.2 in some way to do with mysterious 'index.html' bits appearing after URLs where we thought they shouldn't. We haven't tracked this down and we might not for a while (we just switched back to Five 1.2..), just wanted to let you know Five 1.2 has some compatibility issues.. I was looking at the publisher, and it hacks the URL to explicitely add the default view to it when a default view is used. That might explain it. You're saying Zope 2.10 doesn't do that? I thought it did too. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Nasty error message with obscure bug
On 19 Jun 2006, at 14:59, Chris Withers wrote: Florent Guillaume wrote: 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 ;-) How about opening a ticket in the collector? Is that the right thing to do here? I'm loath to open any another collector entry that will just sit there gathering dust. Hopefully the google archive trail will be enough for this issue... When I look for bugs to fix I don't read the mailing list archives for the past two years, I use the collector. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: default view
Philipp von Weitershausen wrote: Lennart Regebro wrote: On 6/18/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: 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? Yep. browser:defaultView should only affect the view machinery. OK, that means that the test in Five.browser.tests.test_defaultview lin 94 iw wrong, as it explicitly tests that they CAN be attributes. ;) This tests whether an existing ``index_html`` method is still supported and called: >>> print http(r''' ... GET /test_folder_1_/testindex HTTP/1.1 ... ''') HTTP/1.1 200 OK ... Default index_html called From Five.browser.tests.defaultview.zcml: If you want to have non-views as browser default, we still need to use __browser_default__, then. Hmm, perhaps browser:defaultView isn't such a bad idea then... :). Actually, I don't have much of an opinion, to be honest. I just thought that it would make sense that browser:defaultView only modified the behaviour of Zope 3 views. The fact that it also modifies the behaviour of the general traversal machinery in Zope 2 sounds like a blessing if we get to avoid __browser_default__ this way; if it turns out to be a curse for other people, then perhaps we need a five:defaultPublishedName or something... +1 on an alternative spelling, like five:defaultPublishedName or even five:defaultView if that's not too error-prone. Florent The option is to allow attributes, and specify the browserdefault with @@ to force it to be a view. Hmm. ??? That doesn't sound right. Philipp -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: default view
On 18 Jun 2006, at 20:15, Lennart Regebro wrote: If you want to have non-views as browser default, we still need to use __browser_default__, then. The option is to allow attributes, and specify the browserdefault with @@ to force it to be a view. But that wouldn't be compatible with what would happen in pure zope 3, where a default view of '@@foo' would mean the same as ++view+ +@@foo or foo, unless I'm mistaken. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: default view
On 18 Jun 2006, at 12:37, Philipp von Weitershausen wrote: Florent Guillaume wrote: 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). Hey, cool. You know, the real challenge is backporting this all the way to Five 1.2 to ensure compatibility between the current stable Zope 2 releases. I know, unfortunately :( I can't make any promise about that, 2.10/trunk is my priority here. But I think Lennart was working on the same thing on the Five side. Please review the unit test (which pass as is), to check if you agree with the semantics. The unit tests look good except for the default-view-for-attributes issue (see below). By the way, I recommend avoiding ztapi. It isn't officially deprecated, but we try to discourage its use wherever we can. I think it'll be deprecated soon. 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. Yup. 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? Yep. browser:defaultView should only affect the view machinery. Ok. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: default view
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: 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 [EMAIL PROTECTED] 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-dev] Re: Nasty error message with obscure bug
Chris Withers wrote:
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:
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 ;-)
How about opening a ticket in the collector?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Time-based releases a good idea?
On 15 Jun 2006, at 16:09, Philipp von Weitershausen wrote: Chris McDonough wrote: People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. I'm also for reducing duplication, but only to the point that it does not large amounts of break running code. We have yet to see what the real fallout of changing to the Z3 ZPT implementation is. It may be a pure win, but I wouldn't declare victory just yet, at least until we have some empirical evidence that it doesn't break large existing codebases. Oh, I absolutely agree. Zope 2.10 will need strong testing mostly because the ZPT implementation. This was a pretty major change, the few heavy discussions we had so far already are good evidence of that (e.g. the one on empty path expressions). Given all that, it's still a thing we wanted to do and are happy to do. I agree, we can't declare victory on the whole war yet, but at least on a few battles... :) FWIW the CPS 4 trunk (in development for now) works fine with the new zpt implementation, provided you use only unicode everywhere, which we do. Thanks Philip for the move to z3 zpt! Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: OFS.Application deprecations for Zope 2.10
On 14 Jun 2006, at 22:06, Dieter Maurer wrote: Florent Guillaume wrote at 2006-6-13 22:13 +0200: Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. Interestingly, it is usually not the loss for the third party product developers (as they usually gain nothing from their products) -- but for the people using the product. When users repeatedly bitch to the developer because a product doesn't work with a newer Zope version, it's a loss of time for the developer. He would have gained time by doing the correction in advance of the users discovering the problem. Personally, I will simply blame Zope when one of my products breaks for some stupid BBB incompatibility (such as removing "zLOG" or "methods" support in initialization modules) introduced by some Zope release. I will fix them only, when I myself upgrade to a newer Zope and hit the problems (only then, I can reproduce the problem and check that the fix really fixes). I am slowly upgrading (still using Zope 2.8). Unlike Nuxeo, I do not get money (or other rewards) for keeping my products in sync with the current Zope releases. Nuxeo isn't getting money from using Zope 2.10, for instance, it's just that we believe that any improvements is worth putting back into Zope itself (if only so that maintenance is shared and peer-reviewed) and not kept in our own tree. Being interested in improving the framework means that we have to work with it, and it's better to work with something clean than with something that has accumulated years and years of cruft. So we're interested in cleaning up the framework. This means deprecating broken, old or dirty stuff at some point. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: OFS.Application deprecations for Zope 2.10
On 14 Jun 2006, at 00:45, Chris McDonough wrote: On Jun 13, 2006, at 4:13 PM, Florent Guillaume wrote: Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. You're right. This only because I haven't managed to get off 2.8 on any of my projects, so I just never see these warnings. The reason I haven't been able to make it off 2.8 is due mostly to other deprecation/feature addition aggressiveness that has taken place in 2.9 and on the HEAD. Us plain old folks just can't keep up. I really wouldn't at all mind releasing a patched EE if the thing being deprecated was worth deprecating. But IMO this was a bad deprecation, and we should just un-deprecate it. FWIW I patched EE's trunk on svn.zope.org. If we don't remove things at some point, there's no point in doing deprecation warnings. I think the deprecation shouldn't have been done in the first place. This is only about "methods" not about __ac_permissions__ and so on that have warnings in the file. We can push it back to Zope 2.11... Actually I really don't care, I've patched EE. Or we can just pretend we never deprecated 'methods', remove the warning, and get on with it; no harm, no foul. Then the framework never gets cleaned up. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: OFS.Application deprecations for Zope 2.10
On 13 Jun 2006, at 21:51, Tres Seaver wrote: Florent Guillaume wrote: Chris Withers wrote: Chris McDonough wrote: view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it? Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ? If you need monkey patching I don't see why the framework should help you. This should be extremely rare occurences with big comments, not use of a magic 'methods' class attribute. Removing it breaks longstanding and widely-used third-party products, which means that anyone upgrading will have to upgrade the products at the same time. The win in this case is mostly aesthetic, which makes the removal less attractive. Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. And this is only for Zope 2.10 which I doubt these third party products are using at the moment. If we don't remove things at some point, there's no point in doing deprecation warnings. We can push it back to Zope 2.11... Actually I really don't care, I've patched EE. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: OFS.Application deprecations for Zope 2.10
Chris Withers wrote: Chris McDonough wrote: view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it? Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ? If you need monkey patching I don't see why the framework should help you. This should be extremely rare occurences with big comments, not use of a magic 'methods' class attribute. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/trunk/lib/python/AccessControl/tests/framework.py added
Please don't, the only supported method of running tests is through
test.py, and adding "framework.py" everywhere is just more cruft.
Florent
Andreas Jung wrote:
Log message for revision 68592:
added
Changed:
A Zope/trunk/lib/python/AccessControl/tests/framework.py
-=-
Added: Zope/trunk/lib/python/AccessControl/tests/framework.py
===
--- Zope/trunk/lib/python/AccessControl/tests/framework.py 2006-06-12
06:21:11 UTC (rev 68591)
+++ Zope/trunk/lib/python/AccessControl/tests/framework.py 2006-06-12
06:36:06 UTC (rev 68592)
@@ -0,0 +1,44 @@
+##
+#
+# Copyright (c) 2002 Zope Corporation and Contributors. All Rights Reserved.
+#
+# This software is subject to the provisions of the Zope Public License,
+# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
+# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
+# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
+# FOR A PARTICULAR PURPOSE
+#
+##
+
+##
+# Set up unit testing framework
+#
+# The following code should be at the top of every test module:
+#
+# import os, sys
+# execfile(os.path.join(sys.path[0], 'framework.py'))
+#
+# ...and the following at the bottom:
+#
+# framework()
+
+
+# Find the Testing package
+if not sys.modules.has_key('Testing'):
+p0 = sys.path[0]
+if p0 and __name__ == '__main__':
+os.chdir(p0)
+p0 = ''
+p = d = os.path.abspath(os.curdir)
+while d:
+if os.path.isdir(os.path.join(p, 'Testing')):
+sys.path[:1] = [p0, os.pardir, p]
+break
+p, d = os.path.split(p)
+else:
+print 'Unable to locate Testing package.'
+sys.exit(1)
+
+import Testing, unittest
+execfile(os.path.join(os.path.split(Testing.__file__)[0], 'common.py'))
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: OFS.Application deprecations for Zope 2.10
Chris Withers wrote: Florent Guillaume wrote: Anyway for EE the 'methods' use can be replaced by: from OFS.Folder import Folder Folder.externalEdit_ = ExternalEditor() Folder.externalEditLink_ = EditLink And this is supposed to be better?! That's ExternalEditor's problem. At least the monkey patching is explicit, and in line with what the rest of __init__.py does. ExternalEditor is all about monkey patching. Until a sane alternative is available, I'd proprose to un-deprecate these methods... 'methods' in __init__.py is not sane, it's big magic and nobody knows about it or how it works. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] OFS.Application deprecations for Zope 2.10
I wasn't the one who did it, but the rationale is to remove all magic from things in __init__.py and use ZCML instead. Anyway for EE the 'methods' use can be replaced by: from OFS.Folder import Folder Folder.externalEdit_ = ExternalEditor() Folder.externalEditLink_ = EditLink Florent On 9 Jun 2006, at 17:41, Chris McDonough wrote: Jusst out of curiosity, what is the rationale for deprecating "methods"? - C On Jun 9, 2006, at 10:52 AM, Florent Guillaume wrote: OFS.Application has a few deprecations warnings that were supposed to go away in Zope 2.10: __init__.py of %s has a long deprecated '__ac_permissions__' attribute. __init__.py of %s has a long deprecated 'meta_types attribute. __init__.py of %s has a long deprecated 'methods' attribute. Shall we remove them now? Note that ExternalEditors 0.9.1 for instance still used 'methods' but that's its own damn fault. -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] OFS.Application deprecations for Zope 2.10
OFS.Application has a few deprecations warnings that were supposed to go away in Zope 2.10: __init__.py of %s has a long deprecated '__ac_permissions__' attribute. __init__.py of %s has a long deprecated 'meta_types attribute. __init__.py of %s has a long deprecated 'methods' attribute. Shall we remove them now? Note that ExternalEditors 0.9.1 for instance still used 'methods' but that's its own damn fault. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unittests with different zope configuration?
Zope core doesn't use the legacy locations anymore however, right? It would potentially impact only third-party products? Florent On 7 Jun 2006, at 14:47, Stefan H. Holek wrote: It is needed to update "legacy locations", e.g. copying config.instancehome to the INSTANCE_HOME built-in and into the environment. The debug_mode flag has a legacy location of Globals.DevelopmentMode. Cheers, Stefan On 7. Jun 2006, at 14:28, Florent Guillaume wrote: Stefan H. Holek wrote: I use this to set debug-mode off: # Switch off debug mode import App.config config = App.config.getConfiguration() config.debug_mode = 0 App.config.setConfiguration(config) The setConfiguration() is probably unnecessary, you're modifying a mutable datastructure. Florent -- Anything that happens, happens. --Douglas Adams -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Unittests with different zope configuration?
Stefan H. Holek wrote: I use this to set debug-mode off: # Switch off debug mode import App.config config = App.config.getConfiguration() config.debug_mode = 0 App.config.setConfiguration(config) The setConfiguration() is probably unnecessary, you're modifying a mutable datastructure. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PageTemplates/ Merged r68461 from 2.10 branch:
Have you read the discussion on the list about this?
Backward compatibility?
Third-party apps?
Duh.
On 5 Jun 2006, at 14:18, Chris Withers wrote:
Out of interst, why not just make this change wherever empty tales
expreessions have been used in the past?
It'd be clearer as to what the intention was and remove the
necessity for hacky code like this...
cheers,
Chris
Florent Guillaume wrote:
Log message for revision 68462:
Merged r68461 from 2.10 branch:
Empty TALES path expressions are allowed in Zope 2.
http://www.zope.org/Collectors/Zope/2118
Changed:
U Zope/trunk/lib/python/Products/PageTemplates/Expressions.py
U Zope/trunk/lib/python/Products/PageTemplates/tests/
testExpressions.py
-=-
Modified: Zope/trunk/lib/python/Products/PageTemplates/Expressions.py
===
--- Zope/trunk/lib/python/Products/PageTemplates/Expressions.py
2006-06-02 15:02:15 UTC (rev 68461)
+++ Zope/trunk/lib/python/Products/PageTemplates/Expressions.py
2006-06-02 15:04:12 UTC (rev 68462)
@@ -99,6 +99,8 @@
class ZopePathExpr(PathExpr):
def __init__(self, name, expr, engine):
+if not expr.strip():
+expr = 'nothing'
super(ZopePathExpr, self).__init__(name, expr, engine,
boboAwareZopeTraverse)
Modified: Zope/trunk/lib/python/Products/PageTemplates/tests/
testExpressions.py
===
--- Zope/trunk/lib/python/Products/PageTemplates/tests/
testExpressions.py 2006-06-02 15:02:15 UTC (rev 68461)
+++ Zope/trunk/lib/python/Products/PageTemplates/tests/
testExpressions.py 2006-06-02 15:04:12 UTC (rev 68462)
@@ -86,6 +86,15 @@
self.failUnless(isinstance(defer, DeferWrapper))
self.failUnless(isinstance(lazy, LazyWrapper))
+def test_empty_ZopePathExpr(self):
+"""Test empty path expressions.
+"""
+ec = self.ec
+self.assertEquals(ec.evaluate('path:'), None)
+self.assertEquals(ec.evaluate('path: '), None)
+self.assertEquals(ec.evaluate(''), None)
+self.assertEquals(ec.evaluate(' \n'), None)
+
def test_suite():
return unittest.makeSuite(ExpressionTests)
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: CMF/branches/1.6/ - preparing CMF 1.6.1-beta
On 3 Jun 2006, at 20:46, Jens Vagelpohl wrote: On 3 Jun 2006, at 18:49, Florent Guillaume wrote: I didn't see the GenericSetup checkin creating that tag, could you check that you're subscribed (but not receiving mail if you don't want to) to the list http://mail.zope.org/mailman/listinfo/zope-cvs Or are these checkins messages now going somewhere else? I am subscribed to the [EMAIL PROTECTED] list and everything shows up on it. Are you on that list? I am, but not reading mail through it, I'm using Gmane. It seems [EMAIL PROTECTED] is not on Gmane. Should I ask for it to be added? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] default view
In current Zope 2.10, when you have:
and a URL like:
http://.../foodoc/thepage
it seems that the publisher will still use attribute lookup (and
therefore acquisition) before the view if you have a URL like
This is unfortunate because in my case I want to use a page name that
is present as an attribute on all the parents ("view", this is for
CMF), and there seems to be no way of having the Five views take
precedence over attributes and acquisition. What's the reason for
having decided to do it this way? Can this be changed?
A second problem is that even if I specify:
and the URL:
http://.../foodoc/
then "thepage" is still looked up as above, attribute lookup first.
I'm pretty that in this cas we only want view lookup.
Opinions?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py Revert unwanted checkin.
Philipp von Weitershausen wrote: Tres Seaver wrote: Florent Guillaume wrote: Log message for revision 68445: Revert unwanted checkin. Changed: U Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py -=- Modified: Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py === --- Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py 2006-06-01 14:44:13 UTC (rev 68444) +++ Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py 2006-06-01 14:46:17 UTC (rev 68445) @@ -99,8 +99,6 @@ class ZopePathExpr(PathExpr): def __init__(self, name, expr, engine): -if name == 'standard' and not expr: -expr = 'nothing' super(ZopePathExpr, self).__init__(name, expr, engine, boboAwareZopeTraverse) Why revert? I was fine with this, rather than my warning-emitting version. Go ahead and forward-port it to the trunk, and close out the collector issue with a note saying "Zope2 allows empty path expressions" (maybe reference the issue in the code?) Cool, I guess this would answer the questions I had in my last entry of http://www.zope.org/Collectors/Zope/2118. Ok case closed ;) I checked this in: http://svn.zope.org/?view=rev&rev=68461 Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: __contains__ and acquisition problem?
Ok I fixed this for Zope 2.10 and trunk: http://svn.zope.org/?view=rev&rev=68459 Florent Jim Fulton wrote: Anyway, the acquisition wrapper implementation hasn't been updated to handle many slots that were added in recent years, including __contains__. Jim Florent Guillaume wrote: Could anybody shed some light on what's happening here: >>> from Acquisition import Implicit >>> class Impl(Implicit): ... pass >>> class C(Implicit): ... def __getitem__(self, key): ... print 'getitem', key ... if key == 4: ... raise IndexError ... return key ... def __contains__(self, key): ... print 'contains', repr(key) ... return key == 5 The class by itself behaves as expected: >>> c = C() >>> 5 in c contains 5 True >>> 3 in c contains 3 False Let's put c in the context of i: >>> i = Impl() >>> i.c = c Now why is the following happening? Why is __contains__ not used? >>> 3 in i.c # c.__of__(i) getitem 0 getitem 1 getitem 2 getitem 3 True >>> 5 in i.c getitem 0 getitem 1 getitem 2 getitem 3 getitem 4 False -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/trunk/lib/python/AccessControl/ Make python security policy work with a boolean __aatus__
On 1 Jun 2006, at 18:19, Philipp von Weitershausen wrote: Florent Guillaume wrote: On 1 Jun 2006, at 17:53, Philipp von Weitershausen wrote: By the way, a test for isinstance(__aatus__, int) would also be true for booleans because bool inherits from int. I didn't want to touch the p.__class__ part because of security proxies came to my mind... In this case it probably doesn't matter but I didn't want to risk it. So true. OTOH the C code calls PyInt_Check which does the same as isinstance, so I improved 2.10/trunk. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/trunk/lib/python/AccessControl/ Make python security policy work with a boolean __aatus__
On 1 Jun 2006, at 17:53, Philipp von Weitershausen wrote: Florent Guillaume wrote: Log message for revision 68446: Make python security policy work with a boolean __aatus__ Wow, I wasn't aware that only ints were possible. Shouldn't this be backported to Zope 2.9 as well? I consider it a bug when an 1 won't be exchangeable for True in something that's apparently either true of false. Right, I backported it. By the way, a test for isinstance(__aatus__, int) would also be true for booleans because bool inherits from int. I didn't want to touch the p.__class__ part because of security proxies came to my mind... In this case it probably doesn't matter but I didn't want to risk it. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope 2.10 deprecation warnings
FYI I've fixed all this. Florent Florent Guillaume wrote: Current bare Zope 2.10 sends some deprecation warnings because it itself imports things that it deprecates, this will have to be hidden. Suggestions welcome: - App/Product.py imports ZClasses which are deprecated, - Products/ZCatalog/ZCatalog.py imports TextIndex (for the Splitters) but TextIndex is deprecated. Also I've checked in a fix for the ZPT warnings such as: Init Ambiguous name for method of Products.PageTemplates.ZopePageTemplate.ZopePageTemplate: 'manage' != 'manage_main' Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2.10 TALES repeat and 'item'
The following TALES expression using the 'item' name doesn't work: python:repeat['item'].even() Unauthorized: The container has no security assertions. Access to 'even' of (Products.PageTemplates.Expressions.PathIterator object at 0x47986f0) denied. whereas this works: repeat/item/even Anyone knows why? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2.10 deprecation warnings
Current bare Zope 2.10 sends some deprecation warnings because it itself imports things that it deprecates, this will have to be hidden. Suggestions welcome: - App/Product.py imports ZClasses which are deprecated, - Products/ZCatalog/ZCatalog.py imports TextIndex (for the Splitters) but TextIndex is deprecated. Also I've checked in a fix for the ZPT warnings such as: Init Ambiguous name for method of Products.PageTemplates.ZopePageTemplate.ZopePageTemplate: 'manage' != 'manage_main' Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/...
On 31 May 2006, at 19:20, Tres Seaver wrote: I uploaded a similar one, except with deprecation warning, to the collector issue I added: http://www.zope.org/Collectors/Zope/2118 Ah thanks, I missed it. My variation also creates an expression which would raise a KeyError if evaluated, rather than returning None. I don't think anybody can actually be depending on what the current code gives back if an empty expression is called, so yours should be equally fine. If you say it used to return the expression context, then I'm pretty sure nobody used the result. OTOH I'd rather return None just in case, it gives reasonable semantics. WRT dprecation: I would actually prefer no* to have the warning, myself; I don't think that a usage which has been workable for so long is actually in error. I agree, we should just decree "in Zope 2, empty ZPT path expression are allowed and evaluate to None". Florent We should probably add a test which verifies compilability of empty expressions, plus whichever behavior we specify. -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/...
Tres Seaver wrote:
I agree with you that there should be BBB code that provides the old
behavior and I agree with Philipp that not using that old behavior is a
benefit for the CMF.
Sure. I just don't want to *make* people upgrade CMF when upgrading
Zope, unless there is a reason which is important *to the CMF*.
An interesting factoid I found while spelunking this issue: the CMF (by
way of DCWorkflow) is literally the oldest consumer of the expression
machinery outside of ZPT itself! Shane's earliest checkin of the
'Expression' module was nearly 5 years ago, and used an empty string as
the class-level default for the 'text' attribute.
FWIW the following patches gives the proper BBB behaviour.
Shall I check it in? Does it need to send a deprecation warning?
Florent
Index: Products/PageTemplates/Expressions.py
===
--- Products/PageTemplates/Expressions.py (revision 68406)
+++ Products/PageTemplates/Expressions.py (working copy)
@@ -99,6 +99,8 @@
class ZopePathExpr(PathExpr):
def __init__(self, name, expr, engine):
+if name == 'standard' and not expr:
+expr = 'nothing'
super(ZopePathExpr, self).__init__(name, expr, engine,
boboAwareZopeTraverse)
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Five: Feature freeze and release fest tomorrow
Brian Sutherland wrote:
On Wed, May 03, 2006 at 01:32:49AM +0200, Daniel Nouri wrote:
So, after talking to philiKON and jinty on IRC, I wrote this rather
kludgy test that shows that there's a problem with the current
implementation of testbrowser in Five and cookies.
Attached is a patch that contains both the test and the fix. Note that
I couldn't find the time to write a test for Zope 3 that would show that
the Zope 3 setup does *not* eat away your cookies. jinty suggested I
should do that, but I think the included test makes things clear enough.
I just wanted an example of what Zope3 does, but was too lazy to find
one myself. But yeah, your test makes it absolutely clear to me that
this is a bug we need to fix. I'll commit your patch (or something like
it) to the trunk and Five 1.4 branches.
Sometimes it's easier to understand tests than patches or english.
+ >>> response = self.publish('/test_folder_1_')
+ >>> print str(response) # doctest: +ELLIPSIS
+ Status: 200 OK
+ X-Powered-By: Zope (www.zope.org), Python (www.python.org)
+ Content-Length: 0
+ Set-Cookie: evil="cookie"
Interesting, Zope3 does not put quotes around cookie values, but Zope2
always does. I wonder which is right?
Zope 2 was wrong (and it's been reported a number of time that it sometimes
prevent interoperability with other systems) but changing it would break too
much Zope 3 apps.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope 2.10: Remaining tasks
Philipp von Weitershausen wrote: The feature freeze date for the June release is only days away. It was planned to be May 1st, but due to lots of pending branches, we might let it slip for a *couple* of days (not more!). I've compiled a rough list of outstanding tasks for Zope 2.10: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/Tasks Please complete and/or correct this list. It is up to the release managers (Stephan, Andreas) and the Pope to decide the exact feature freeze date, but I would suggest that we start merging those branches real soon. Another small task I know Julien Anguenot would like to do is fix the zpt engine (in Zope 3 I guess now) to work properly with mixed html/xhtml inclusion of macros. He's done most of the work with Fred Drake at the end of last year, but never got around to intergrate it. He's on a project deadline for now, but I believe will be available in the next few day (around wednesday?) to check that in. It could even be seen as a bugfix, really. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/easter-sprint_traversal-refactor/lib/python/ZPublisher/BaseRequest.py Now using an adapter. Two tests fail in Five, and I don't know why.
I know this code was just refactored and exists in stock Zope 2, but it made me see this: Lennart Regebro wrote: +class DefaultPublishTraverse(object): [...] +# 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. +doc = getattr(subobject, '__doc__', None) +if doc is None: +doc = getattr(object, '%s__doc__' % name, None) This should avoid acquisition and be performed on aq_base(object) I believe. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: request.debug needed for Zope 3 ZPT engine
Philipp von Weitershausen wrote: Several components that we'd like to use in Zope2, such as the SequenceEngine from Zope3, use the Zope 3 ZPT engine to render some things. (This has nothing to do with Zope 2 using or not using the Zope 3 ZPT engine.) The Zope 3 ZPT engine, in particular zope.app.pagetemplate.ViewPageTemplateFile, makes the assumption that 'request' properly implements IBrowserRequest. The Zope 2 request doesn't implement all of it, but it's close enough to make most of the Zope 3 stuff work. ViewPageTemplateFile, however, uses the 'debug' property of the request (it's specified in the request interface). This 'debug' property is an instance of DebugFlags and basically is a debugging switch for ZPT and other things. The Zope 2 request obviously doesn't have this 'debug' property. In the past we've usually added the necessary properties to the Zope 2 request in such cases. We could do this again, however: The Zope 2 request allows form data access through the __getattr__ protocol (the Zope 3 request does this through __getitem__). request.debug would shadow a potential 'debug' form variable and might break applications that make use of this form variable (I would expect there are at least a couple). Note that the obvious workaround is to use request.form['debug'] or request.cookies['debug'], depending on where you get the variable from. I would even say that this should be the preferred way of getting to form variables or cookies. But given the antiqueness of the Zope 2 API and no truly encouraged way of accessing things, there is to be expected code that relies on request.debug being the form variable. I would still vote for introducing the change. At some point (perhaps even in Zope 2.10), we'll want to use more and more of the Zope 3 ZPT engine. This problem would reoccur then. I'm therefore going to introduce the change on the zope33-port branch, as it is necessary for getting Five 1.5 (see Five's zope33-port branch) and Zope 2 to work with Zope 3.3. We can't potentially break currently perfectly working applications. I'd propose either: - introduce a config flag somewhere (zope.conf), off by default, switching the zope 2 REQUEST.debug to not using form/cookies/others but the proper attribute that zope 3 expects, - or make a deep hack in zope 2 request's __getattr__ for the 'debug' case to check the caller stack for the few cases we know are needed from zope 3 code (zpt engine for instance), and at the same time emit a warning that direct access to REQUEST.debug is deprecated and that people should use __getitem__ access. Do we also want to think about deprecating __getattr__ access to REQUEST in general? Given that the zope 2 core is not cleaned of it (I'm sure -- though I haven't looked), it would mean total deprecation wouldn't be done before 1.5 years anyway... Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Reminder: Feature Freeze May 1
Jim Fulton wrote: Don't forget that the feature freeze for the June release is May 1! That is only 10 days away! New features should be check in in a *stable* form by then. While we won't necessarily do a beta release then, anything checked in for the new release must be ready for a beta release when it is checked into the trunk. What's the ETA for merging the various branches? Yours in Z3, Phil's in Z2, maybe Five... ? I'd rather have them sooner than later. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: favicon.ico for 2.10?
kit BLAKE wrote: 2006/4/24, Jens Vagelpohl <[EMAIL PROTECTED]>: Yeah, that's nice. Does it work as a PNG, though? I was under the impression (and thought the spec requires) that favicons must be *.ico files. A PNG favicon will work in the Mozilla family, but not in IE. kit However I'd be surprised if a .gif didn't work. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ANN] pythonproducts 1.0beta1 released
Cool. What's the status of it regarding integration directly into Zope 2.10? Florent Rocky Burt wrote: I'm pleased to announce the first beta release of pythonproducts. pythonproducts == Description A mechanism to construct Zope 2 products as regular python packages. This enables a python package to be deployed as a Zope 2 product using a similar strategy as Zope 3. Author/Maintainer `Rocky Burt <[EMAIL PROTECTED]>`__ Latest Release `1.0beta1 <http://dev.serverzen.com/site/projects/pythonproducts/releases/pythonproducts-1-0beta1-tar.gz/download>`__ License BSD-style, see LICENSE.txt for details Source Control http://codespeak.net/svn/z3/pythonproducts/ Requirements - Python 2.3.5 or higher in 2.3.x series - Zope 2.8 or 2.9 - Five 1.2 or higher -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Traversal issue which affects Five
Hi Alec, Five traversal is definitely very touchy, and the interactions with Zope numerous. So I'm sure the problem you observed is real and that a solution must be found. The unit tests you propose would go a long way to having a fix committed asap, so yes please, provide one. Florent Alec Mitchell wrote: It seems that the way OFS.Traversable.restrictedTraverse() handles security checking on objects with __bobo_traverse__ methods is considerably different from the way it normally checks security. The result is that traversal cannot obtain attributes using acquisition from objects that are marked . In the normal case, security is checked using guarded_getattr, which gets an attribute and checks the permissions on the retrieved object in its original context. For __bobo_traverse__methods which return simple properties (say strings), it is impossible to determine the container from which the returned attribute originates, so unless the attribute was not acquired, an Unauthorized error will always be raised. Objects that are Five Traversable always have __bobo_traverse__ methods which attempt to mimic normal traversal, which effectively means that the security checks end up preventing acquisition of simple properties using traversal from ever working on these objects (say using a TAL path expression 'context/attribute' which you expect to be acquired). Unfortunately, because Five has no control over the security checks done during traversal, this cannot be fixed directly in Five. However, IMHO fixing this makes sense for Zope itself, provided there aren't any undesirable consequences. I propose that if the validation of a __bobo_traverse result raises Unauthorized, that we make one last check to see if the result o 'guarded_getattr(obj, name)' is identical to the result of the __bobo_traverse__ call and allow it if that's the case. Here is my proposed patch against Zope 2.9 trunk: --- Traversable.py (revision 66323) +++ Traversable.py (working copy) @@ -201,9 +201,18 @@ else: # Can't determine container container = _none -if not securityManager.validate( -obj, container, name, next): -raise Unauthorized, name +try: +if not securityManager.validate( +obj, container, name, next): +raise Unauthorized, name +except Unauthorized: +# If next is a simple unwrapped property, it's +# parentage is indeterminate, but it may have been +# acquired safely. In this case validate will raise +# an error, and we can check that our value was +# acquired safely. +if guarded_getattr(obj, name, marker) is not next: +raise Unauthorized, name else: if restricted: next = guarded_getattr(obj, name, marker) At the moment Plone 2.5 is really struggling with this issue, and it would be wonderful if a fix for this could go into Zope 2.8 and 2.9 soon. I'm happy to write tests for this, I just want to make sure that I'm not proposing something really wrong/inappropriate here. Generally, the validate() call should return a True or False value, so this change should have little performance impact except in the case where 'container == _none' and validate would otherwise raise a very unhelpful unauthorized error. Your feedback is much appreciated. Alec Mitchell ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3 server+publication refactor for z2
Hi, Sidnei has been working on the Zope 2 publication-refactor branch where he's allowed the use of the Zope 3 Twisted-based server, and of a Zope 3 based publication process. I'd like to see this merge branched in Zope 2 trunk because I'd like Zope 2.10 to be Twisted-based. What's missing from the branch preventing this? What problems have been encountered? (This query is a reaction to my diving in to current asyncore+medusa +ThreadedAsync+PubCore that gives me nightmares when I realize I'll have to implement new server types or new stuff more akin to the ZEO storage server.) Thanks, Florent PS: what do people think of changing ZEO so that it integrates with Twisted properly instead of relying on a private event loop hack [please move to zodb-dev if you answer this] -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Checkins] SVN: Zope/trunk/ Fixed collector 2057: Testing.makequest broke getPhysicalPath()
Paul Winkler wrote:
Using an Item or Folder as your root object for tests works fine except for
this one issue, so why not allow that?
My feeling is that setting up an app is unnecessary work when you
don't need one; for one thing, your test module needs to call
Zope2.startup() first; for another, afaict creating a Zope2.app is
a couple orders of magnitude slower than creating a SimpleItem.
So maybe more people *should* use makerequest(NotAnApp) ;-)
FWIW usually in my tests I rarely use makerequest.
On the other hand, when testing things that use traversal, it's very common
that I have to define a fake root object whose getPhysicalPath returns
('',). It's only a few line, and makes my tests self-contained and much
easier to understand than relying on the magic of a testing framework
library (which I tend to hate).
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: TCP CLOSE_WAIT leaks
Alan Milligan wrote: I managed to get a DeadlockDebugger trace on this thing, it made very interesting reading: Ah you did, good. I was surprised by your earlier statement saying that the fact that all threads were used was preventing it from working, this shouldn't be the case. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/trunk/lib/python/OFS/Traversable.py using startswith()
Why? x[0] is much faster than x.startswith().
Or do you expect to have empty path components?
Florent
Andreas Jung wrote:
Log message for revision 65598:
using startswith()
-=-
Modified: Zope/trunk/lib/python/OFS/Traversable.py
===
--- Zope/trunk/lib/python/OFS/Traversable.py2006-02-28 16:59:49 UTC (rev
65597)
+++ Zope/trunk/lib/python/OFS/Traversable.py2006-02-28 17:17:12 UTC (rev
65598)
@@ -173,7 +173,7 @@
name = path_pop()
__traceback_info__ = path, name
-if name[0] == '_':
+if name.startswith('_'):
# Never allowed in a URL.
raise NotFound, name
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Deprecating Zope 2 interfaces?
yuppie wrote: Chris Withers wrote: Philipp von Weitershausen wrote: That's a bold assumption. It's a bold assumption based on the fact that I'm pretty sure there's about 1 person on the planet who's ever used that code. I believe his name's Andreas. I might be wrong of course, but I don't think it's much more than that... I guess you are just talking about IFAwareObjectManager, not about WriteLockInterface and PluggableIndexInterface. You might want to grep through CMF 1.6 or CMF 2.0 to adjust your assumptions. IFAwareObjectManager is used in several places. Yep, and building on CMF, CPS 3.4 now uses it too (with Zope 3 interfaces of course). Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Python warnings behavior and stacklevel=2
Julien Anguenot wrote: Tim Peters wrote: [Julien Anguenot] I'm having some problems with the warnings module behavior. (Python-2.4.2 and Zope-2.9 trunk) [... traceback ... ] - Line 71 Module zLOG, line 140, in LOG Module warnings, line 61, in warn Module warnings, line 67, in warn_explicit TypeError: unsubscriptable object I've had this too, and I believe it appears if you have a frame referencing a python script (or maybe an external method) in the stack. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Inhibit URL-traversal
Dario Lopez-Kästen wrote: Greetings, for a product I am writing, i need to experiment with inhibiting URL-traversal to the methods and subobjects of it. I still wnat the methods and objects to be available via direct call, for instance: from a script or template: container.my_product_instance.some_method(...) but not http://some/url/my_product_instance/some_method?... In effect I am hiding that part of the zodb for external access- Also, can such a behaviour be imposed on templates (they being methods really) and Script(Python)s? Have your methods accept a REQUEST=None optional argument, and if it's not None then you were called through an URL. In that case you can redirect or raise a Unauthorized or NotFound or whatever. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Deprecation process issues
Tres Seaver wrote: I've noticed a couple of problems with recent deprecation decisions (for OFS.content_types and zLOG). The major one is that the deprecation warning waw added without removing the code in the core which depends on the deprecated feature. The most obvious sign of this is that the tests no longer "run clean", but are cluttered up with warning output. Yes this is a major pain. Such that in my sandboxes the first thing I do is comment out the warning in zLOG. Florent Another issue is that at least one of those choices (the zLOG one) seemed to land without accounting for the legitimate use cases which the new "blessed" method doesn't address (e.g, logging levels not offered by the standard 'logging' module). I'm about to check in changes which clean out the use of OFS.content_types, but am less willing to clean up the zLOG uses until the other use cases are addressed. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope tests: 6 OK, 2 Failed
The problem is that when I do: bin/zopectl test -s AccessControl everything works fine. However the buildbots do: python test.py -s AccessControl and this fails. I included a workaround, . Florent Stefan H. Holek wrote: AFAIK the default configuration used by tests does not have a dbtab. See lib/python/App/config.py. Stefan On Jan 14, 2006, at 16:45, Florent Guillaume wrote: I'll look at it. Florent Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This failure is tie up with Florent's recent checkin: Log message for revision 41303: When a database is created "by hand" from a custom_zodb.py during startup, we still want to put it in the dbtab multidatabases dict. This happens when unit tests call Zope2.startup(), because Testing has a specific custom_zodb.py loaded at startup that uses a DemoStorage. Zope tests summarizer wrote: Summary of messages to the zope-tests list. Period Fri Jan 13 12:01:01 2006 UTC to Sat Jan 14 12:01:01 2006 UTC. There were 8 messages: 8 from Zope Unit Tests. Test failures - Subject: FAILED : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:10:37 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004008.html Subject: FAILED : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:12:07 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004009.html -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope tests: 6 OK, 2 Failed
I'll look at it. Florent Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This failure is tie up with Florent's recent checkin: Log message for revision 41303: When a database is created "by hand" from a custom_zodb.py during startup, we still want to put it in the dbtab multidatabases dict. This happens when unit tests call Zope2.startup(), because Testing has a specific custom_zodb.py loaded at startup that uses a DemoStorage. Zope tests summarizer wrote: Summary of messages to the zope-tests list. Period Fri Jan 13 12:01:01 2006 UTC to Sat Jan 14 12:01:01 2006 UTC. There were 8 messages: 8 from Zope Unit Tests. Test failures - Subject: FAILED : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:10:37 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004008.html Subject: FAILED : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:12:07 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004009.html Tests passed OK --- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:01:32 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004002.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:03:06 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004003.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:04:36 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004004.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:06:06 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004005.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:07:36 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004006.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Jan 13 21:09:07 EST 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-January/004007.html -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: BTreeFolder2.objectIds() - accessing _tree.keys() slow
[EMAIL PROTECTED] wrote: I have very large BTreeFolder2 (CMFMember via BaseBTreeFolder in Archetypes) - has about 260k items in _tree - objectIds() is painfully slow, as is self._tree.keys() Independently of the fastest way, I'm curious what use case you have to have a need to get all the keys of a big BTree. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zLOG module deprecated
Lennart Regebro wrote: I've never had the need to use them. No, but other people do. That's different from not wanting to use them. The more choice you have, the more trouble you have. I agree that a TRACE level might be of interest. But BLATHER and PROBLEM is competely overhead from my point of view - in fact I can't explain when to use BLATHER or TRACE compared to DEBUG. But I can, and so can Florent. "PROBLEM" I agree about. I have never heard that one before, and I don't see why you can't use ERROR or WARNING. Stop focusing on 'PROBLEM', it's just an alias for 'WARNING'. Florent ERROR: Something didn't work. WARNING: There is something fishy here, I'm guessing how it should be handled. INFO: Nothing is wrong, but this is important. (For example Zope server ready to handle requests). VERBOSE: Nothing is wrong and this may be important. (For example the info saying what IP-adress and port the zope server is started on.) DEBUG: For debug information. TRACE: I need to have a lot of information now! I find all this fairly self-evident and highly useful, and se absolutely zero reason for removing them, when they are so useful. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zLOG module deprecated
On 9 Jan 2006, at 17:20, Fred Drake wrote: On 1/9/06, Florent Guillaume <[EMAIL PROTECTED]> wrote: My point is that the python logging levels are insufficiently fine grained. The python logging framework leaves room for numeric levels and registering equivalent strings, and indeed ZODB and zLOG have them defined. I want to use them. Do you need someone else to define a constant for the level you want before you can use them? There's a API in the logging module that allows you to pass the desired level in. I see no reason to require a constant to be defined outside your code. It's useful to have them standardized so that the logging module can output a standard string for them in the logs. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zLOG module deprecated
On 9 Jan 2006, at 17:25, Andreas Jung wrote: --On 9. Januar 2006 17:06:25 +0100 Florent Guillaume <[EMAIL PROTECTED]> wrote: My point is that the python logging levels are insufficiently fine grained. Sufficently enough for me. "Sufficient for me" is not a good reason sorry. If you don't want to use them, then don't use them. BLATHER & TRACE can be merged to DEBUG and PROBLEM to either WARN|ERROR. This should be even enough for Zope. No it can't. TRACE is already being used, and it would drown everyone using DEBUG if it was at DEBUG level. Same thing, BLATHER would drown people looking for succint INFO. The python logging framework leaves room for numeric levels and registering equivalent strings, and indeed ZODB and zLOG have them defined. Of course zLOG has all levels defined for backward compatibility. An application should possibly defines its own logger with all possibilities the logging module offers when it has the need for additional logging levels. I will standardize those for the use case we're seeing time and again and again. - verbose INFO -> BLATHER, which i want to rename VERBOSE - verbose DEBUG -> TRACE Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: SVN: Zope/trunk/lib/python/StructuredText/ Sanely deprecate StructuredText by making it a facade of zope.structuredtext.
On 9 Jan 2006, at 17:03, Andreas Jung wrote: --On 9. Januar 2006 17:00:13 +0100 Florent Guillaume <[EMAIL PROTECTED]> wrote: Philipp von Weitershausen wrote: Log message for revision 41225: Sanely deprecate StructuredText by making it a facade of zope.structuredtext. Just to make sure: we didn't lose the "ReST allowed arbitrary file includes" bugfix by doing this? structuredtext != reST Ooops my mistake, sorry. I hadn't thought zope 3 was using something as old as structuredtext :) Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zLOG module deprecated
On 9 Jan 2006, at 16:55, Fred Drake wrote: On 1/9/06, Andreas Jung <[EMAIL PROTECTED]> wrote: ZODB defines these levels but I can not see any code in the ZODB package that actually uses these levels. Nobody should be using the zLOG levels with the logging package, but rather use the logging package levels. So in the end, there's no need for Zope to be defining levels at all, only conventions for how the levels are used. My point is that the python logging levels are insufficiently fine grained. The python logging framework leaves room for numeric levels and registering equivalent strings, and indeed ZODB and zLOG have them defined. I want to use them. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/trunk/lib/python/StructuredText/ Sanely deprecate StructuredText by making it a facade of zope.structuredtext.
Philipp von Weitershausen wrote: Log message for revision 41225: Sanely deprecate StructuredText by making it a facade of zope.structuredtext. Just to make sure: we didn't lose the "ReST allowed arbitrary file includes" bugfix by doing this? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zLOG module deprecated
Andreas Jung wrote: the zLOG module will be offically deprecated in Zope 2.10 (removed in Zope 2.12). New code _must_ use the 'logging' module of Python. And please help to replace all outstanding code that uses the zLOG module on the _trunk_ (which is a fun job :-|). If that is the case then I intend to: 1. move the definitions of zope's specific levels (trace and blather) into a more prominent place (ZODB also defines these levels, but it has to be an independent package), 2. rename 'blather' to 'verbose', 3. push back a number of framework logs that are done on every request at the trace level (as they were before the move to python's logging module), I'm thinking of transaction logs here. This leaves the 'debug' level free for application debugging. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/2.9/ Move to ZODB 3.6 final.
Hi, Why not use the tag you just made? ZODB svn://svn.zope.org/repos/main/ZODB/tags/3.6.0/src/ZODB etc. (Hi have a vague feeling this may have been discussed before but I'm not sure ;)). Florent Tim Peters wrote: Log message for revision 41156: Move to ZODB 3.6 final. Changed: _U Zope/branches/2.9/doc/ _U Zope/branches/2.9/lib/python/ _U Zope/branches/2.9/utilities/ -=- Property changes on: Zope/branches/2.9/doc ___ Name: svn:externals - ZEO -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/doc/ZEO + ZEO -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/doc/ZEO Property changes on: Zope/branches/2.9/lib/python ___ Name: svn:externals - ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/BTrees persistent -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/persistent ThreadedAsync -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ThreadedAsync transaction-r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/transaction ZEO-r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZEO ZODB -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZODB ZopeUndo -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZopeUndo zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/pytz zodbcode -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/zodbcode ClientCookie -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/ClientCookie mechanize -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/mechanize + ZConfigsvn://svn.zope.org/repos/main/ZConfig/tags/ZConfig-2.3.1 BTrees -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/BTrees persistent -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/persistent ThreadedAsync -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ThreadedAsync transaction-r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/transaction ZEO-r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZEO ZODB -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZODB ZopeUndo -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/ZopeUndo zdaemon-r 40792 svn://svn.zope.org/repos/main/zdaemon/trunk/src/zdaemon pytz -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/pytz zodbcode -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/zodbcode ClientCookie -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/ClientCookie mechanize -r 40992 svn://svn.zope.org/repos/main/Zope3/branches/3.2/src/mechanize Property changes on: Zope/branches/2.9/utilities ___ Name: svn:externals - ZODBTools -r 41065 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/scripts + ZODBTools -r 41153 svn://svn.zope.org/repos/main/ZODB/branches/3.6/src/scripts ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.10] ZPT going Unicode
Dieter Maurer wrote: I'd rather have a one-time update method that trawls the database, like is done for Python Scripts recompiling for instance. Or I can call it myself in my upgrade procedures on the exact objects I know will need updates. I've implemented the setstate() variant as proof-of-concept. I am not sure if there is overhead for CMF-based sites since they FSPageTemplates inherit from PageTemplateFile which has nothing in mind with persistence. So only persistent ZopePageTemplate would be affected. If there is need for a dedicated migration we could easily write one..that's the lamest task of the whole ZPT unicode issue :-) Modern ZODB versions allow modifications made in "__setstate__" to be reliably persisted. This means that "__setstate__" updates can now be one time (though the test whether an upgrade is necessary is done always). The "recompile" hack for "PythonScript"s would no longer be necessary. I know but that means you have backward compatibility cruft that stays there forever. And no good way to tell the administrators how to upgrade before a given date. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope 2.10] ZPT going Unicode
Andreas Jung wrote: ToDo: in-place conversion of persistent ZPT instance through setstate() or so... Could we avoid doing things in __setstate__ please? It imposes a runtime cost that doesn't disappear. I'd rather have a one-time update method that trawls the database, like is done for Python Scripts recompiling for instance. Or I can call it myself in my upgrade procedures on the exact objects I know will need updates. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope tests: 7 OK, 1 Failed
Test failing: Zope-trunk. I guess it's not been updated to use latest 3.2. Error in test testParseRealDateTime (zope.i18n.tests.test_formats.TestDateTimeFormat) Traceback (most recent call last): File "/usr/local/python2.4/lib/python2.4/unittest.py", line 260, in run testMethod() File "/home/stefan/autotest/temp/python24-zope210/lib/python/zope/i18n/tests/test_formats.py", line 277, in testParseRealDateTime 'd. HH:mm:ss z'), File "/home/stefan/autotest/temp/python24-zope210/lib/python/zope/i18n/format.py", line 140, in parse tzinfo = pytz.FixedOffset(hours * 60 + mins) AttributeError: 'module' object has no attribute 'FixedOffset' and the like. Florent Zope tests summarizer wrote: Summary of messages to the zope-tests list. Period Fri Dec 23 12:01:01 2005 UTC to Sat Dec 24 12:01:01 2005 UTC. There were 8 messages: 8 from Zope Unit Tests. Test failures - Subject: FAILED : Zope-trunk Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Dec 23 21:12:32 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003841.html Tests passed OK --- Subject: OK : Zope-2_6-branch Python-2.1.3 : Linux From: Zope Unit Tests Date: Fri Dec 23 21:02:01 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003834.html Subject: OK : Zope-2_6-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Fri Dec 23 21:03:31 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003835.html Subject: OK : Zope-2_7-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Fri Dec 23 21:05:01 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003836.html Subject: OK : Zope-2_7-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Dec 23 21:06:31 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003837.html Subject: OK : Zope-2_8-branch Python-2.3.5 : Linux From: Zope Unit Tests Date: Fri Dec 23 21:08:01 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003838.html Subject: OK : Zope-2_8-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Dec 23 21:09:31 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003839.html Subject: OK : Zope-2_9-branch Python-2.4.2 : Linux From: Zope Unit Tests Date: Fri Dec 23 21:11:02 EST 2005 URL: http://mail.zope.org/pipermail/zope-tests/2005-December/003840.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope 2.9b2 and sessions
I'm in the middle of debugging important session machinery problems with the current zope 2.9 branch. (ReadConflictErrors happening when everything should be mvcc). Could the 2.9b2 release please hold until this can be resolved? FWIW I have a semi-reproducible testcase so I'm making progress. I hope by Saturday night it will be over -- but I'm having to learn the TemporaryStorage code at the same time. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] clockserver
What happens if the request started by clockserver takes a long time or hangs? Will the next tick start a new one anyway, or will it be blocked? Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope-2.9 r40780 make install doesn't finish, files missing from bin
Martijn Faassen wrote: Andreas Jung wrote: I agree. I am also not happy with that. Unfortunately I have currently no clue how to solve this issue (no idea about zpkg). WHat you can do is the following: - copy the checkout to the location where your software home should be - run "configure; make inplace; make instance" Doesn't work for me; I don't have a bin/mkzopeinstance after this procedure so I still cannot create instances. Sigh. I use utilities/mkzopeinstance.py (until moves again...) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: buildbot failure in Zope branches 2.9 2.4 Windows 2000 zc-bbwin
[EMAIL PROTECTED] wrote:
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Windows 2000
zc-bbwin.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 2398
Blamelist: efge,sidnei
BUILD FAILED: failed test
FYI test output is:
C:\WINDOWS\system32\cmd.exe /c c:\python24\python.exe test.py -v -m
!^^(ZEO|zope[.]app[.]) --all
in dir C:\buildbot\.org\zc-bbwin--Windows
2000--Zope---branches---2.9--2.4\build (timeout 1200 secs)
argv: ['C:\\WINDOWS\\system32\\cmd.exe', '/c', 'c:\\python24\\python.exe
test.py -v -m !^^(ZEO|zope[.]app[.]) --all']
environment: {'TMP': 'C:\\DOCUME~1\\buildbot\\LOCALS~1\\Temp',
'COMPUTERNAME': 'BBWIN', 'LIB': 'C:\\Program Files\\Microsoft Visual Studio
.NET 2003\\SDK\\v1.1\\Lib\\', 'USERDOMAIN': 'BBWIN', 'PYTHON':
'c:\\python24\\python.exe', 'COMMONPROGRAMFILES': 'C:\\Program Files\\Common
Files', 'PROCESSOR_IDENTIFIER': 'x86 Family 15 Model 4 Stepping 1,
GenuineIntel', 'PROGRAMFILES': 'C:\\Program Files', 'PROCESSOR_REVISION':
'0401', 'SYSTEMROOT': 'C:\\WINDOWS', 'PATH':
'C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;c:\\utils;C:\\Program
Files\\Subversion\\bin', 'VIM': 'C:\\Program Files\\Vim', 'TEMP':
'C:\\DOCUME~1\\buildbot\\LOCALS~1\\Temp', 'PROCESSOR_ARCHITECTURE': 'x86',
'VS71COMNTOOLS': 'C:\\Program Files\\Microsoft Visual Studio .NET
2003\\Common7\\Tools\\', 'APR_ICONV_PATH': 'C:\\Program
Files\\Subversion\\iconv', 'ALLUSERSPROFILE': 'C:\\Documents and
Settings\\All Users', 'INSTANCE_HOME':
'C:\\buildbot\\.com\\bbwin--Windows--FIPS-1---trunk--2.4\\build\\instance',
'SESSIONNAME': 'Console', 'HOMEPATH': '\\Documents and Settings\\buildbot',
'USERNAME': 'buildbot', 'LOGONSERVER': 'BBWIN', 'PROMPT': '$P$G',
'COMSPEC': 'C:\\WINDOWS\\system32\\cmd.exe', 'PATHEXT':
'.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH', 'INCLUDE': 'C:\\Program
Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include\\',
'FP_NO_HOST_CHECK': 'NO', 'WINDIR': 'C:\\WINDOWS', 'HOMEDRIVE': 'C:',
'APPDATA': 'C:\\Documents and Settings\\buildbot\\Application Data',
'SYSTEMDRIVE': 'C:', 'NUMBER_OF_PROCESSORS': '1', 'SVN_SSH':
'c:/putty/plink.exe', 'PROCESSOR_LEVEL': '15', 'OS': 'Windows_NT',
'USERPROFILE': 'C:\\Documents and Settings\\buildbot'}
'zope[.]app[.])' is not recognized as an internal or external command,
operable program or batch file.
program finished with exit code 255
Florent
--
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [RfC] Removal of old stuff in Zope 2.10
Andreas Jung wrote: for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy: - ZopeTutorial (could be ripped off without implications and made available for download on zope.org) +1 - HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers) +0, it would be useful to not use the explanation texts that are in the help system, or at list check that other material (docstrings, zope book) are at least as comprehensive. - Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org. Gadfly should go, but OTOH have sqlite in its place would still provide SQL inside Zope and that could be a good plus. And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list). +1 as I don't use ZClasses and don't intend to maintain them. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] '-C' in REQUEST.form ?
I have a strange thing in Zope 2.8 and Zope 2.9 I never noticed.
{'-C': ''} is present in REQUEST.form for a GET request without
arguments.
A simple script "showrequest" with "return repr
(context.REQUEST.form)" shows it.
A bit of digging shows this is due to cgi.py which has the code (in
parse()):
if sys.argv[1:]:
qs = sys.argv[1]
else:
qs = ""
And Zope is actually run with the command line:
/usr/local/bin/python /opt/zope28/lib/python/Zope2/Startup/run.py -C /
home/fg/zope28/etc/zope.conf
which explains the '-C'.
What should we do? Clear sys.argv[1:] on Zope start?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: sessions in the presence of conflicts
[Using zope-dev@ instead of [EMAIL PROTECTED] Dennis Allison wrote: A more session-friendly conflict resolution might use: 1. if any of the states are invalid (that is, has a key '_invalid') return the invalid state. 2. if any any of the states attributes ['token','id','_created'] differ then there is a conflict, raise the conflict exception. 3. order the newState and savedState by modification time (or if that cannot be computed, by access time). 4. any key appearing in oldState's dictionary but not appearing in both savedState and newState should be removed from all. This corresponds to a key-value pair being deleted in one of the transactions. Insertions will be managed automatically by the updates. 5. beginning with the oldest, update oldState dictionary of key-value pairs using the dictionary part of newState and savedState. Return oldState. This does several things. First, it captures independent key-value changes made in both potentially conflicting transactions. Second, it provides a reasonable ordering for multiple (potentially conflicting) key-value pair updates. Third, it manages insertions and deletions to the session variable set in the presence of conflicts. Does this make sense? I have yet to figure out how to map a TransientObject "state" back to the object it represents, but it clearly is possible. I certainly makes sense from a high level description, but the devil is in the details. I'd be interested in looking at it if you code something. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: RFV: Unicode in Zope 2
Martijn Faassen wrote: Jim Fulton wrote: Martijn Faassen wrote: [snip] I'll volunteer to help brainstorm on this, but right now my brainstorm is only very dark and full of lightning. You and I brainstormed this a few months ago. I think this was on the list. I think that, for starters, we would arrange that all Zope 3 views used in Zope 2 would get unicode input. If you like, I can try to find this discussion. :) Ah, right, that is far less scary, indeed. Your post somehow gave me the impression you wanted to change the way current Zope 2 does things, but if you limit yourself to what happens with Zope 3 stuff in Zope 2, it's less scary. In fact Five already has hacks to make sure that unicode enters Five-generated forms. Replacing these hacks with something solid would be good. Anyway, in some basics, Zope 2 does have an approach to unicode for *output* that's fairly similar to Zope 3's: if you use unicode strings your entire output (including page templates) will be unicode (if you don't mix with non-unicode non-ascii strings..). Then the response encoding setting is read and everything is transformed once to unicode text. Silva uses this. It also struggles to make sure all its input is transformed to unicode (among other ways using Formulator). In Plone, the situation is quite different -- its PlacelessTranslationService monkeypatches into the page template engine and puts in ways so that you can mix UTF-8 and unicode strings together. This then goes on to break assumptions of code that uses the page template engine in a unicode-pure environment (which is what happened to Silva). Ick. I'm not suggesting this is easy. We may have some messy deprecation and backward compatibility code. But we *do* need to solve this problem eventually, and the solution doesn't get any closer without taking steps. Yes. I'm optimistic about being able to do this for Five-related stuff. If this is eventually going to be people's main development system, then we can basically say we've solved the important unicode issues. What I'm worried about doing this for old code, but some steps will probably become clear during the brainstorming session. Migration tools that turn strings in the ZODB into unicode ones magically (with the ability to spell out exceptions and encoding)? Tricky... I'd start by adding some deprecation warnings at the places where PlacelessTranslationService (or Localizer for that matter) do their workarounds so that normally incompatible types are mixed together. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Please vote about conflict errors logging
Ok after a week the consensus is pretty much in favor of 1. INFO 2. no traceback 3. ERROR So here's what I'll do: 1. There's enough votes for BLATHER that I'll add zope.conf option to change the level, but it will default to INFO. 2. No traceback will be logged anymore. Note that you'll still have the traceback from point 3. 3. Here maybe things were unclear. Everybody agrees that the error should happen at ERROR level, but I must point out again that no explicit logging is needed because it is already done if you configure error_log to copy exceptions to the event.log. So I propose another little change: have the error_log copy to event.log be the default behaviour. Today the default is off. Florent Florent Guillaume wrote: Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: RFC: Locale-specific Text Collation
Jim Fulton wrote: When presenting users with ordered text (e.g. sorted lists of options), simply sorting Unicode strings doesn't provide an ordering that users in a given locale will find useful. Various languages have text sorting conventions that don't agree with the ordering of Unicode code points. (This is even true for English. Generally, users prefer to see text sorted without regard to case.) A proposal to address this problem is here: http://dev.zope.org/Zope3/LocaleSpecificTextCollation Comments are welcome. +1, no comment :) Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/tags/2.9.0b1/2.9/ Zope 2.9.0 b1
Andreas Jung wrote: Log message for revision 40580: Zope 2.9.0 b1 Changed: A Zope/tags/2.9.0b1/2.9/ -=- Copied: Zope/tags/2.9.0b1/2.9 (from rev 40579, Zope/branches/2.9) Huh, did you really want to do that? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: AcceleratedHTTPCache and virtual hosting (collector 1447)
Paul Winkler wrote: To the other respondents: Thanks for the suggestions, but I do not consider making AcceleratedHTTPCacheManager more flexible to be a "test turd". Tres outlined a real use case for changing the code (see below). I don't understand why you guys consider this more invasive than monkeypatching, which is capable of causing obscure breakage in far-flung tests. But thanks anyway. Coding for testability is quite important, and is a credo of some of the trendy methodologies these days. I consider it perfectly acceptable to have a class attribute ConnectionClass for httplib.HTTPConnection or a method like "getConnection" that can then be subclassed or modified during tests. Provided it does not important performance issues. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zLOG deprecation?
Chris Withers wrote: # In the days of zLOG, there were 7 standard log levels, and ZODB/ZEO used # all of them. Here's how they map to the logging package's 5 standard # levels: # #zLOG logging #---- #PANIC (300) FATAL, CRITICAL (50) #ERROR (200) ERROR (40) #WARNING, PROBLEM (100) WARN (30) #INFO (0) INFO (20) #BLATHER (-100) none -- defined here as BLATHER (15) #DEBUG (-200) DEBUG (10) imnsho, blather and debug are the wrong way round. blather should go away completely, it's a stupid name anyway :-( Just because you don't see the use in something doesn't mean it has to go away. In my book BLATHER is used for "verbose INFO" and is different than DEBUG and TRACE (both levels are useful too). INFO and BLATHER are for the administrator. DEBUG and TRACE are for the developer. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ObjectManager.hasObject
I've added a long needed hasObject method to ObjectManager. Note that BTreeFolder2 has had it for a long time and it's quite useful. Enjoy. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Please vote about conflict errors logging
Here's my own vote :) 1. Do you want these ConflictErrors retried logs to be at level: BLATHER 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? No, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: ERROR Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Please vote about conflict errors logging
Please vote for the level at which you want to log retried conflict errors. These are the ConflictErrors that aren't returned to the user but automatically retried by the Zope publisher. 1. Do you want these ConflictErrors retried logs to be at level: - INFO - BLATHER - DEBUG - not logged - other 2. In addition, please specify if you feel those retried ConflictErrors should have their full traceback logged? - Yes, with traceback - No, without traceback 3. Finally, please tell us if the ConflictErrors that *can't* be retried (and are returned to the user as an error, and are also logged to the error_log) should be additionally explicitely logged to the event log, and at which level: - ERROR - not logged - other (Also, if you feel the logging should be different between 2.8 and 2.9, please say so.) I'll wait until Wednesday morning to collect results. Thanks, Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 20:50, Dieter Maurer wrote: Florent Guillaume wrote at 2005-12-2 13:33 +0100: ... Please no. Don't put anything at INFO. A conflict error is either something normal that should be at level BLATHER or below, or an ERROR that a sysadmin wants to see logged as such. I strongly disagree with you: "ConflictError"s are essential hints that your system might come into trouble (they can turn into real error). These hints are at least as important as e.g. 2005-12-02T07:17:59 INFO ZODB.Mount Opening database for mounting: '144160968_1010482273.050062' -- 2005-12-02T07:17:59 INFO ZODB.Mount Mounted database '144160968_1010482273.050062' at /temp_folder Looks like "INFO" is a better level than "BLATHER"... If you look at the way their purpose is explained in zLOG, you'll see that level INFO is reserved for things like server startup and shutdown. Or, as shown above, initial mounting of databases. Anything recurring that can happen many times in the life of the server but does not pose any problems should *not* be visible at INFO. On the other hand, that's exactly what BLATHER is for folks! Use it! Note that it's another reason for not using the default python loggers who have a stupidly small number of levels. If you want to audit your server status to see if there are changes real errors will happen, INFO is *not* the level to use. Anyway, there's sufficient disagreement here, I'll send another mail to ask for people's votes. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 20:40, Dieter Maurer wrote: Florent Guillaume wrote at 2005-12-1 19:49 +0100: I've improved the logging of ConflictError in Zope 2.9 and trunk. http://svn.zope.org/?rev=40454&view=rev Now you'll get two things: - logs at level BLATHER for each conflict, but it may be retried - log at level ERROR when the conflict can't be retried anymore and is returned to the browser as an error. Apparently, you stopped following our thread (you, Chris, me): In my view, a "ConflictError" observed by the user should be treated exactly like any other exception observed by the user: it should go through the "error_log" and "standard_error_message". That's what my patch did. It might be logged (when the user decides that exceptions seen by the user should be logged). I can agree with that. The approach to achieve this it to fix a bug in Zope's "zpublisher_exception_hook", not to add an explicit log when the final retry fails (though the extra log entry will not hurt significantly). The patch I did included the fix you proposed in the patch in the mailing list archives based on the collector entry. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 11:09, Chris Withers wrote: I was planning on rolling my changes out to 2.8, 2.9 and the trunk. Unless anyone strenuously objects, I still intend to do that. I cleaned up a lot of the code and made a few other changes that generally improve logging. I strenuously object to you overwriting without consultation code I just checked in and that was approved by at least 3 people. And I'm totally -1 on any logging at level INFO or above about retriable conflict errors. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Logging of ConflictError
On 2 Dec 2005, at 11:09, Chris Withers wrote: Damn, I was working on this at the same time :-S Florent Guillaume wrote: I've improved the logging of ConflictError in Zope 2.9 and trunk. http://svn.zope.org/?rev=40454&view=rev Now you'll get two things: - logs at level BLATHER for each conflict, but it may be retried - log at level ERROR when the conflict can't be retried anymore and is returned to the browser as an error. In my work, I've actually changed this to use the new, proper logging calls. I'll be comitting later this morning. It doesn't really matter, zLOG has a compatibility layer that ends up doing the same thing. I removed the log at level INFO because it is very misleading for system administrators in my experience. I don't think so, I've actually changed and enhanced this in my work. You now get a log at INFO whenever a conflict occurs. It includes more information than the old version, as you'll see... Please no. Don't put anything at INFO. A conflict error is either something normal that should be at level BLATHER or below, or an ERROR that a sysadmin wants to see logged as such. INFO sucks for recurring stuff like that that in addition contain the word "error" which it isn't. I can't count the number of sysadmin/customers/ hosting providers that freak out when something like that appears in the log and call us and we have to explain that yes, it's not logical but... Do people want this also for 2.8? Note that it changes the log format, so may break third party tools that parse logs. I was planning on rolling my changes out to 2.8, 2.9 and the trunk. Unless anyone strenuously objects, I still intend to do that. I cleaned up a lot of the code and made a few other changes that generally improve logging. It's a shame Florent and I were genuinely working on this at the same time without the other knowing... Well, I told you on the list that I was already working on this. You didn't pay attention I guess. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Logging of ConflictError
I've improved the logging of ConflictError in Zope 2.9 and trunk. http://svn.zope.org/?rev=40454&view=rev Now you'll get two things: - logs at level BLATHER for each conflict, but it may be retried - log at level ERROR when the conflict can't be retried anymore and is returned to the browser as an error. I removed the log at level INFO because it is very misleading for system administrators in my experience. Do people want this also for 2.8? Note that it changes the log format, so may break third party tools that parse logs. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
Dieter Maurer wrote: Hanno Schlichting wrote at 2005-11-26 09:28 +0100: ... I hope to have tracked the ~200 failing tests down to two of your changes in OFS.CopySupport. The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several "Folder" like classes are likely to overwrite "_setObject" and "_delObject". Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. I checked in a backward compatibility check for this too. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
On 26 Nov 2005, at 09:28, Hanno Schlichting wrote:
The second change is actually related to your permission work.
First of all I have to thank you for your great work :) But I have
found one nasty thing.
CopySupport had the following security declaration:
__ac_permissions__=(('Copy or Move', (), ('Anonymous', 'Manager',)),)
...
Globals.default__class_init__(CopySource)
which changed into:
security = ClassSecurityInfo()
security.setPermissionDefault(copy_or_move, ('Anonymous', 'Manager'))
...
InitializeClass(CopySource)
Now the InitializeClass call is actually an alias for the former
Globals call, so no change here. But as you wrote yourself, you had
some trouble with the mysterious __ac_permissions format.
Looking at the actual code in App.class_init in the last paragraph
I'm quite sure that the former code did effectivly nothing so far.
The actual setattr call is inside a 'for mname in mnames:' loop
where mnames is the second element of each security tuple - in this
special case the mysterious () which results in not going through
the 'for mname in mnames:' loop at all.
Ok I just fixed SecurityInfo, could you update AccessControl/ and
recheck please?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
Dieter Maurer wrote: Hanno Schlichting wrote at 2005-11-26 09:28 +0100: ... I hope to have tracked the ~200 failing tests down to two of your changes in OFS.CopySupport. The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several "Folder" like classes are likely to overwrite "_setObject" and "_delObject". Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. Ok, due to popular demand I'll make such a change. I'm a bit peeved though at the lack of willingness from the few people that have reimplemented their version of _setObject/_delObject (which could be considered "private" APIs, seeing that they're prefixed with an underscore) to just modify their code for forward compatibility and be done with it, but instead have us embark in a year-long deprecation strategy. This is supposed to be open source, can't we be reactive to change in such situation? Are folks really going to ship their framework code with _setObject unmodified from the current version when they ship it for Five 1.2 or Zope 2.9? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Python2.4 Security Audit ETA???
The security audit already happened, and led to checkins by Jim on October 26 that preceded the release of Zope 2.8.4. Zope 2.8.4 is safe to use with python 2.4. Florent Alan Milligan wrote: Aeons ago someone promised that said Zope security audit of Python 2.4 was scheduled for October. I've not yet seen any happy announcements that Zope is now 2.4 compliant, and do want to highlight the importance of achieving this goal. Python2.4 has been out for almost a year now, and it's fairly ubiquitous. There've been many statements made on this list about people quite happily running their Zope's - contrary to white hat advice. With the major distro's, Python is entrenched in their installer and gui processes and *all* packaging is focused around a single python (2.4 for everyone excepting our BastionLinux). In reality it is infeasible to support a second version of Python for Z2. Many modules have SWIG bindings (while core Z2 doesn't require much of this, a number of products do), requiring multiple package versions - build systems cannot cope with this scenario without massive spec customisations (which is all pointless given the window of this requirement - and of course that we've all actually learnt something for python2.5, python2.6 ) We are getting an increasing number of people attempting to load incompatible packages. It is not possible to downgrade python. Most of userland is not competent to get a secondary python2.3 installation running - especially when packages such as python-ldap are simply not available for their old python and new ldap etc etc which all requires custom package builds. We are also stuck in a time-warp actually having to back-port a large proportion of recent linux packages because we'd like to make new features available, increasing costs and testing requirements. It is also no longer possible for customers to subscribe to just a single channel because our core is substantially different to their chosen vendor's installation, and packages will be installed into meaningless python paths etc. Can someone please give me an ETA on this, so I can decide if and how to support zope in light of other pressing linux requirements for our distro. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
Dieter Maurer wrote: The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several "Folder" like classes are likely to overwrite "_setObject" and "_delObject". Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. Maybe. But on the other hand I'd rather not have object manager code slowed down and uglified to suit the negligibly small number of classes that are in this case, and that can be trivialy upgraded in a forward-compatible manner. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
On 26 Nov 2005, at 09:28, Hanno Schlichting wrote:
Florent Guillaume wrote:
I've done a big checkin to switch practically everything to the
new- style (actually they're 5 years old) security declarations.
I'd appreciate if another set of eyes could double-check
everything; while I've taken a number of steps to ensure I didn't
make mistakes you never know...
http://mail.zope.org/pipermail/zope-checkins/2005-November/
030103.html
Thanks,
Florent
Hi Florent.
I have spent some time to run all unit tests of Plone (2.1.1) and
all it's core products on Zope 2.9 and look into the failing tests.
Thanks a lot!
I hope to have tracked the ~200 failing tests down to two of your
changes in OFS.CopySupport.
The first change is in the manage_pasteObjects method of
CopyContainer. There are some _setObject and _delObject calls which
grew a new suppress_events parameter. This breaks the reference
implementation of Archetypes because it uses something based on
BTreeFolder2 to store references and BTreeFolder2 overwrites both
_setObject and _delObject with its own versions.
The BTreeFolder2 inside Zope 2.9 has been modified to also take this
suppress_events parameter. I'm afraid Plone/AT will have to modify
its _setObject and _delObject implementations to take this optional
parameter too.
As I'm quite new to Zope internals I suppose fixing BTreeFolder2 is
the right thing here (adding the new parameter on both of its
methods). But this change might effect some more products which
have overwritten these methods as CopySupport is a base class of
OFS.Folder and so probably of every folderish type out there.
This was the minimal necessary change to have events work. These
products will have to be modified to work with Zope 2.9, there's no
avoiding it. Fortunately the changes are obvious and minimal. BTW
what BTreeFolder2 are you talking about? BTreeFolder2 has been
included in Zope for a while.
The second change is actually related to your permission work.
First of all I have to thank you for your great work :) But I have
found one nasty thing.
CopySupport had the following security declaration:
__ac_permissions__=(('Copy or Move', (), ('Anonymous', 'Manager',)),)
...
Globals.default__class_init__(CopySource)
which changed into:
security = ClassSecurityInfo()
security.setPermissionDefault(copy_or_move, ('Anonymous', 'Manager'))
...
InitializeClass(CopySource)
That's correct.
Now the InitializeClass call is actually an alias for the former
Globals call, so no change here. But as you wrote yourself, you had
some trouble with the mysterious __ac_permissions format.
Looking at the actual code in App.class_init in the last paragraph
I'm quite sure that the former code did effectivly nothing so far.
The actual setattr call is inside a 'for mname in mnames:' loop
where mnames is the second element of each security tuple - in this
special case the mysterious () which results in not going through
the 'for mname in mnames:' loop at all.
Yes the previous code did nothing, and it just left the
__ac_permissions__ alone.
The new code goes through SecurityInfo.ClassSecurityInfo.apply and,
because there has been a setPermissionDefault, has an available
self.roles dict... Hm I see what's wrong, the SecurityInfo code only
generates permission default roles for permissions which are *also*
mentioned in a method permission setting (the for loop). That code is
wrong, I'll have to fix it.
In the Plone unit tests this results in about 190 failing tests
Could you give me the reference to one or two of these failing tests
so that I can check things are ok after the fix? Is this with a
standard Plone-2.1.1 tarball? Do you run the Plone tests using the
standard Zope method?
as inserting an object into a folder isn't allowed anymore for
normal members because this triggers some code in a Referenceable
class which is based on CopySupport directly, which required no
extra permission so far but now is protected through the 'Copy or
Move' permission.
While I guess that protecting the class with this permission has
been the intent it was not in effect so far. So this should be
either reconsidered or at least noted in the changelog. Changing
this in Archetypes shouldn't be a problem (though I'm very new to
Zope's permissions system).
The class is not protected by copy_or_move, the effect of the
declaration is supposed to be that copy_or_move is by default granted
to Anonymous and Manager. But with my changes because of the
aforementioned bug it's not anymore.
Thanks again for reviewing this! I'll prepare a fix soon.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTE
