[Zope-Checkins] Re: [Checkins] SVN: Products.Five/trunk/ Now you can use the old registry with the new API for registerig components.

[Florent Guillaume]

On 27 Jul 2006, at 16:15, Lennart Regebro wrote:

Modified: Products.Five/trunk/site/localsite.py
===
--- Products.Five/trunk/site/localsite.py	2006-07-27 13:51:25 UTC  
(rev 69270)
+++ Products.Five/trunk/site/localsite.py	2006-07-27 14:15:46 UTC  
(rev 69271)

@@ -16,12 +16,26 @@
 $Id$
 

+from operator import xor
+def one_of_three(a, b, c):
+# Logical table for a three part test where only one can be true:
+# 0 0 0: 0
+# 0 0 1: 1
+# 0 1 0: 1
+# 0 1 1: 0
+# 1 0 0: 1
+# 1 0 1: 0
+# 1 1 0: 0
+# 1 1 1: 0
+return xor(xor(a, b), c) and not (a and b and c)


Heh, boolean algebra is nice but sometimes integers convey the  
meaning much better:

  return int(a)+int(b)+int(c) == 1

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]



___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] Re: [Checkins] SVN: Products.Five/trunk/ Now you can use the old registry with the new API for registerig components.

[Florent Guillaume]

Indeed :)


On 29 Jul 2006, at 00:39, Benji York wrote:


Florent Guillaume wrote:

On 27 Jul 2006, at 16:15, Lennart Regebro wrote:

Modified: Products.Five/trunk/site/localsite.py
===
--- Products.Five/trunk/site/localsite.py	2006-07-27 13:51:25  
UTC  (rev 69270)
+++ Products.Five/trunk/site/localsite.py	2006-07-27 14:15:46  
UTC  (rev 69271)

@@ -16,12 +16,26 @@
$Id$


+from operator import xor
+def one_of_three(a, b, c):
+# Logical table for a three part test where only one can be  
true:

+# 0 0 0: 0
+# 0 0 1: 1
+# 0 1 0: 1
+# 0 1 1: 0
+# 1 0 0: 1
+# 1 0 1: 0
+# 1 1 0: 0
+# 1 1 1: 0
+return xor(xor(a, b), c) and not (a and b and c)
Heh, boolean algebra is nice but sometimes integers convey the   
meaning much better:

   return int(a)+int(b)+int(c) == 1


Hey, this is fun!  How about this:

def only_one(*args):
return sum(bool(i) for i in args) == 1
--
Benji York
Senior Software Engineer
Zope Corporation


--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]



___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-dev] Re: 2.9.4? reStructuredText support?

[Florent Guillaume]

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 RD
+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-Checkins] SVN: Zope/branches/2.10/lib/python/OFS/Traversable.py Correct view traversal security checks

[Florent Guillaume]

Log message for revision 69002:
  Correct view traversal security checks

Changed:
  U   Zope/branches/2.10/lib/python/OFS/Traversable.py

-=-
Modified: Zope/branches/2.10/lib/python/OFS/Traversable.py
===
--- Zope/branches/2.10/lib/python/OFS/Traversable.py2006-07-06 04:15:00 UTC 
(rev 69001)
+++ Zope/branches/2.10/lib/python/OFS/Traversable.py2006-07-06 13:44:01 UTC 
(rev 69002)
@@ -260,6 +260,10 @@
 
 if next is not None:
 next = next.__of__(obj)
+if restricted:
+if not securityManager.validate(
+obj, obj, name, next):
+raise Unauthorized, name
 elif bobo_traverse is not None:
 # Attribute lookup should not be done after 
 # __bobo_traverse__:

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/OFS/Traversable.py Merged 69002 from 2.10 branch:

[Florent Guillaume]

Log message for revision 69003:
  Merged 69002 from 2.10 branch:
Correct view traversal security checks
  

Changed:
  U   Zope/trunk/lib/python/OFS/Traversable.py

-=-
Modified: Zope/trunk/lib/python/OFS/Traversable.py
===
--- Zope/trunk/lib/python/OFS/Traversable.py2006-07-06 13:44:01 UTC (rev 
69002)
+++ Zope/trunk/lib/python/OFS/Traversable.py2006-07-06 13:45:15 UTC (rev 
69003)
@@ -260,6 +260,10 @@
 
 if next is not None:
 next = next.__of__(obj)
+if restricted:
+if not securityManager.validate(
+obj, obj, name, next):
+raise Unauthorized, name
 elif bobo_traverse is not None:
 # Attribute lookup should not be done after 
 # __bobo_traverse__:

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/OFS/Traversable.py Code cleanup.

[Florent Guillaume]

Log message for revision 69004:
  Code cleanup.
  

Changed:
  U   Zope/branches/2.10/lib/python/OFS/Traversable.py

-=-
Modified: Zope/branches/2.10/lib/python/OFS/Traversable.py
===
--- Zope/branches/2.10/lib/python/OFS/Traversable.py2006-07-06 13:45:15 UTC 
(rev 69003)
+++ Zope/branches/2.10/lib/python/OFS/Traversable.py2006-07-06 14:24:13 UTC 
(rev 69004)
@@ -118,7 +118,7 @@
 return path
 
 security.declarePrivate('unrestrictedTraverse')
-def unrestrictedTraverse(self, path, default=_marker, restricted=0):
+def unrestrictedTraverse(self, path, default=_marker, restricted=False):
 Lookup an object by path.
 
 path -- The path to the object. May be a sequence of strings or a slash
@@ -139,10 +139,6 @@
 if not path:
 return self
 
-_getattr = getattr
-_none = None
-marker = _marker
-
 if isinstance(path, str):
 # Unicode paths are not allowed
 path = path.split('/')
@@ -151,27 +147,25 @@
 
 REQUEST = {'TraversalRequestNameStack': path}
 path.reverse()
-path_pop=path.pop
+path_pop = path.pop
 
 if len(path)  1 and not path[0]:
 # Remove trailing slash
-path.pop(0)
+path_pop(0)
 
 if restricted:
-securityManager = getSecurityManager()
-else:
-securityManager = _none
+validate = getSecurityManager().validate
 
 if not path[-1]:
 # If the path starts with an empty string, go to the root first.
 path_pop()
-self = self.getPhysicalRoot()
-if (restricted
-and not securityManager.validate(None, None, None, self)):
-raise Unauthorized, name
+obj = self.getPhysicalRoot()
+if restricted and not validate(None, None, None, obj):
+raise Unauthorized(name)
+else:
+obj = self
 
 try:
-obj = self
 while path:
 name = path_pop()
 __traceback_info__ = path, name
@@ -182,102 +176,98 @@
 
 if name == '..':
 next = aq_parent(obj)
-if next is not _none:
-if restricted and not securityManager.validate(
-obj, obj,name, next):
-raise Unauthorized, name
+if next is not None:
+if restricted and not validate(obj, obj, name, next):
+raise Unauthorized(name)
 obj = next
 continue
 
-bobo_traverse = _getattr(obj, '__bobo_traverse__', _none)
+bobo_traverse = getattr(obj, '__bobo_traverse__', None)
 try:
 if name and name[:1] in '@+':
 # Process URI segment parameters.
 ns, nm = nsParse(name)
 if ns:
 try:
-next = namespaceLookup(ns, nm, obj, 
-   
self.REQUEST).__of__(obj)
-if restricted and not securityManager.validate(
+next = namespaceLookup(
+ns, nm, obj, self.REQUEST).__of__(obj)
+if restricted and not validate(
 obj, obj, name, next):
-raise Unauthorized, name
+raise Unauthorized(name)
 except TraversalError:
 raise AttributeError(name)
-elif bobo_traverse is not _none:
+elif bobo_traverse is not None:
 next = bobo_traverse(REQUEST, name)
 if restricted:
 if aq_base(next) is not next:
 # The object is wrapped, so the acquisition
 # context is the container.
 container = aq_parent(aq_inner(next))
-elif _getattr(next, 'im_self', _none) is not _none:
+elif getattr(next, 'im_self', None) is not None:
 # Bound method, the bound instance
 # is the container
 container = next.im_self
-elif _getattr(aq_base(obj), name, marker) == next:
+elif getattr(aq_base(obj), name, _marker) is next:
 # Unwrapped direct attribute of the object so
 # object is the 

[Zope-Checkins] SVN: Zope/trunk/lib/python/OFS/Traversable.py Code cleanup.

[Florent Guillaume]

Log message for revision 69005:
  Code cleanup.

Changed:
  U   Zope/trunk/lib/python/OFS/Traversable.py

-=-
Modified: Zope/trunk/lib/python/OFS/Traversable.py
===
--- Zope/trunk/lib/python/OFS/Traversable.py2006-07-06 14:24:13 UTC (rev 
69004)
+++ Zope/trunk/lib/python/OFS/Traversable.py2006-07-06 14:25:04 UTC (rev 
69005)
@@ -118,7 +118,7 @@
 return path
 
 security.declarePrivate('unrestrictedTraverse')
-def unrestrictedTraverse(self, path, default=_marker, restricted=0):
+def unrestrictedTraverse(self, path, default=_marker, restricted=False):
 Lookup an object by path.
 
 path -- The path to the object. May be a sequence of strings or a slash
@@ -139,10 +139,6 @@
 if not path:
 return self
 
-_getattr = getattr
-_none = None
-marker = _marker
-
 if isinstance(path, str):
 # Unicode paths are not allowed
 path = path.split('/')
@@ -151,27 +147,25 @@
 
 REQUEST = {'TraversalRequestNameStack': path}
 path.reverse()
-path_pop=path.pop
+path_pop = path.pop
 
 if len(path)  1 and not path[0]:
 # Remove trailing slash
-path.pop(0)
+path_pop(0)
 
 if restricted:
-securityManager = getSecurityManager()
-else:
-securityManager = _none
+validate = getSecurityManager().validate
 
 if not path[-1]:
 # If the path starts with an empty string, go to the root first.
 path_pop()
-self = self.getPhysicalRoot()
-if (restricted
-and not securityManager.validate(None, None, None, self)):
-raise Unauthorized, name
+obj = self.getPhysicalRoot()
+if restricted and not validate(None, None, None, obj):
+raise Unauthorized(name)
+else:
+obj = self
 
 try:
-obj = self
 while path:
 name = path_pop()
 __traceback_info__ = path, name
@@ -182,102 +176,98 @@
 
 if name == '..':
 next = aq_parent(obj)
-if next is not _none:
-if restricted and not securityManager.validate(
-obj, obj,name, next):
-raise Unauthorized, name
+if next is not None:
+if restricted and not validate(obj, obj, name, next):
+raise Unauthorized(name)
 obj = next
 continue
 
-bobo_traverse = _getattr(obj, '__bobo_traverse__', _none)
+bobo_traverse = getattr(obj, '__bobo_traverse__', None)
 try:
 if name and name[:1] in '@+':
 # Process URI segment parameters.
 ns, nm = nsParse(name)
 if ns:
 try:
-next = namespaceLookup(ns, nm, obj, 
-   
self.REQUEST).__of__(obj)
-if restricted and not securityManager.validate(
+next = namespaceLookup(
+ns, nm, obj, self.REQUEST).__of__(obj)
+if restricted and not validate(
 obj, obj, name, next):
-raise Unauthorized, name
+raise Unauthorized(name)
 except TraversalError:
 raise AttributeError(name)
-elif bobo_traverse is not _none:
+elif bobo_traverse is not None:
 next = bobo_traverse(REQUEST, name)
 if restricted:
 if aq_base(next) is not next:
 # The object is wrapped, so the acquisition
 # context is the container.
 container = aq_parent(aq_inner(next))
-elif _getattr(next, 'im_self', _none) is not _none:
+elif getattr(next, 'im_self', None) is not None:
 # Bound method, the bound instance
 # is the container
 container = next.im_self
-elif _getattr(aq_base(obj), name, marker) == next:
+elif getattr(aq_base(obj), name, _marker) is next:
 # Unwrapped direct attribute of the object so
 # object is the container
 

[Zope-dev] Re: Proposal: Scrap zpkg for Zope2 releases

[Florent Guillaume]

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 RD
+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-Checkins] SVN: Zope/branches/2.10/lib/python/OFS/ Fixed refactored traversal on bound methods of classes with no default

[Florent Guillaume]

Log message for revision 68980:
  Fixed refactored traversal on bound methods of classes with no default
  access.
  

Changed:
  U   Zope/branches/2.10/lib/python/OFS/Traversable.py
  U   Zope/branches/2.10/lib/python/OFS/tests/testTraverse.py

-=-
Modified: Zope/branches/2.10/lib/python/OFS/Traversable.py
===
--- Zope/branches/2.10/lib/python/OFS/Traversable.py2006-07-05 16:13:42 UTC 
(rev 68979)
+++ Zope/branches/2.10/lib/python/OFS/Traversable.py2006-07-05 16:53:20 UTC 
(rev 68980)
@@ -237,11 +237,11 @@
 if not validated:
 raise Unauthorized, name
 else:
-if hasattr(aq_base(obj), name):
+if getattr(aq_base(obj), name, marker) is not marker:
 if restricted:
-next = guarded_getattr(obj, name, marker)
+next = guarded_getattr(obj, name)
 else:
-next = _getattr(obj, name, marker)
+next = _getattr(obj, name)
 else:
 try:
 next=obj[name]
@@ -249,6 +249,9 @@
 # Raise NotFound for easier debugging
 # instead of AttributeError: __getitem__
 raise NotFound, name
+if restricted and not securityManager.validate(
+obj, obj, _none, next):
+raise Unauthorized, name
 
 except (AttributeError, NotFound, KeyError), e: 
 # Try to look for a view
@@ -270,13 +273,10 @@
 next = _getattr(obj, name, marker)
 except AttributeError:
 raise e
-if next is marker:
-# Nothing found re-raise error
-raise e
-
-if restricted and not securityManager.validate(
-obj, obj, _none, next):
-raise Unauthorized, name
+if next is marker:
+# Nothing found re-raise error
+raise e
+
 obj = next
 
 return obj

Modified: Zope/branches/2.10/lib/python/OFS/tests/testTraverse.py
===
--- Zope/branches/2.10/lib/python/OFS/tests/testTraverse.py 2006-07-05 
16:13:42 UTC (rev 68979)
+++ Zope/branches/2.10/lib/python/OFS/tests/testTraverse.py 2006-07-05 
16:53:20 UTC (rev 68980)
@@ -68,6 +68,24 @@
 return 0
 
 
+class ProtectedMethodSecurityPolicy:
+Check security strictly on bound methods.
+
+def validate(self, accessed, container, name, value, *args):
+if getattr(aq_base(value), 'im_self', None) is None:
+return 1
+
+# Bound method
+if name is None:
+raise Unauthorized
+klass = value.im_self.__class__
+roles = getattr(klass, name+'__roles__', object())
+if roles is None: # ACCESS_PUBLIC
+return 1
+
+raise Unauthorized(name)
+
+
 class UnitTestUser( Acquisition.Implicit ):
 
 Stubbed out manager for unit testing purposes.
@@ -103,6 +121,22 @@
 bb_status = 'screechy'
 
 
+class Restricted(SimpleItem):
+Instance we'll check with ProtectedMethodSecurityPolicy
+
+getId__roles__ = None # ACCESS_PUBLIC
+def getId(self):
+return self.id
+
+private__roles__ = () # ACCESS_PRIVATE
+def private(self):
+return 'private!'
+
+# not protected
+def ohno(self):
+return 'ohno!'
+
+
 class BoboTraversableWithAcquisition(SimpleItem):
 
A BoboTraversable class which may use acquisition to find objects.
@@ -210,6 +244,17 @@
 self.failUnlessRaises(
 KeyError, self.folder1.unrestrictedTraverse,  '/folder1/file2/' )
 
+def testTraverseMethodRestricted(self):
+self.root.my = Restricted('my')
+my = self.root.my
+my.id = 'my'
+noSecurityManager()
+SecurityManager.setSecurityPolicy(ProtectedMethodSecurityPolicy())
+r = my.restrictedTraverse('getId')
+self.assertEquals(r(), 'my')
+self.assertRaises(Unauthorized, my.restrictedTraverse, 'private')
+self.assertRaises(Unauthorized, my.restrictedTraverse, 'ohno')
+
 def testBoboTraverseToWrappedSubObj(self):
 # Verify it's possible to use __bobo_traverse__ with the
 # Zope security policy.

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

Re: [Zope-dev] local namespace optimizations?

[Florent Guillaume]

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 RD
+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?

[Florent Guillaume]

[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 RD
+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] Re: database conflict errors

[Florent Guillaume]

Jean-Marc Orliaguet wrote:

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jonathan wrote:
 
- Original Message - From: Tres Seaver 
[EMAIL PROTECTED]
   

Jonathan wrote:
 

During recent load testing of a new application 3.1% to 7.6% of all
http requests resulted in conflict errors
(3.1% with 10 simultaneous users; 7.6% with 50 simultaneous users).

The conflict error occurs when the application attempts to write a
small image object into a temporary folder, and each conflict error
generates the same traceback:

ConflictError: database conflict error (oid 0x07, class
Products.TemporaryFolder.TemporaryFolder.SimpleTemporaryContainer)



I am running Zope 2.9.2 on CentOS 4.3 (linux).

Does anyone have any ideas as to what I could do to reduce/eliminate
these conflict errors?


First, make sure that your application is not trying to overwrite the
*same* image in each request.  If it needs to do that, then the
conflicts are unavoidable.

Next, making simultaneous writes into any naive container is going to
cause conflicts.  You need to think carefully about how you want those
writes to work, and plan to minimize conflicts:

 - Use a BTreeFolder, rather than a normal OFS.Folder (or derivative).

 - Arrange for the IDs of your images to be substantially different,
   typically by mangling in a random number (or, for instance, the
   microseconds value of the current timestamp).
  

The ids are assigned sequentially, so they never collide, but should id
be 'substantially different' to improve BTreeFolder2 performance?



Sequential IDs can be problematic:  they lead to many more bucket splits
(and therefore conflicts) in the BTree.  Adding some entropy (like a
random number or the milliseconds of the time) *earlier* in the key than
any sequence number, will help keep splits down to a minimum.

  


that's interesting. I did a test once to see what effect it would have 
to add objects with a completely random id to a BTree folder (OOBTree in 
that case) instead of using the object's type nam and add a number at 
the end - and the result was the opposite in term of read performance. 
Looking up keys was much faster if the ids followed a pattern like:


- something-1
- something-2
...


Sure, in single-threaded mode this will decrease performance because the 
keys are spread randomly among all the buckets so many more buckets get 
written.


But in multi-threaded mode, this very spreading leads to better conflict 
resolution behavior.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[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).

[Florent Guillaume]

://mail.zope.org/mailman/listinfo/checkins


--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+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

[Florent Guillaume]

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 RD
+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] Re: Issue 1896: manage_changeProperties() vs manage_addProperty()

[Florent Guillaume]

Berthold Stöger wrote:

Hello,

in Issue #1896 (http://www.zope.org/Collectors/Zope/1896), I describe a
difference in the behaviour of manage_changeProperties() and of
manage_addProperty(): An array of ints is converted to an array of strings
with manage_addProperty(), but not with manage_changeProperties().

You closed the bug with the following comment:


Type converters only deal with the outer type but not with the types of
contained elements. This should be handled on the application level. 


Well, first of all this isn't true as my script shows (note: the report has a
buggy test script, correct one attached): When using manage_addProperty(),
the contents of the array *are* converted from integers to strings.
Or maybe I'm reading you wrong?

Furthermore, this still doesn't explain why  the two functions behave
differently. Digging a bit deeper, I found out that the culprit is in
lib/python/OFS/PropertyManager.py:

In manage_addProperty() the type_converter is always called, but
in _updateProperty() the type_converter is only called if the value is a
string. Similar code can be found in lib/python/OFS/PropertySheets.py

Maybe there is some reason for this behaviour, but I can't think of one.
Either of the following diffs (of course not both!) fixes the problem for me:



I've reopened the bug.

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Import Modules

[Florent Guillaume]

Andreas Jung wrote:

I manage my own servers developing web applications and I would like to
remove the import restrictions of python modules in python scripts. Is it
possible? How can I allow other modules to be imported? I have been using
external modules but it is starting to become nonproductive since I have
to create functions to simple problems like md5, re, etc, and just using
the needed modules would be much simple.


Check for allow_module(). However this is *not* a solution for all and 
everything. There are several that will define not work properly with 
PythonScript (including 're'). 


See Products/PythonScripts/README.txt for a description of how to enable 
regexps in python scripts.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Import Modules

[Florent Guillaume]

Andreas Jung wrote:

I manage my own servers developing web applications and I would like to
remove the import restrictions of python modules in python scripts. Is it
possible? How can I allow other modules to be imported? I have been using
external modules but it is starting to become nonproductive since I have
to create functions to simple problems like md5, re, etc, and just using
the needed modules would be much simple.


Check for allow_module(). However this is *not* a solution for all and 
everything. There are several that will define not work properly with 
PythonScript (including 're'). 


See Products/PythonScripts/README.txt for a description of how to enable 
regexps in python scripts.


Sorry, I meant Products/PythonScripts/module_access_examples.py

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]

___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: How to commit a piece of data in a transaction when the transaction is being aborted later

[Florent Guillaume]

William Heymann wrote:
I am dealing with a zope system where Verisign is sending a POST to our server 
for ecommerece purposes. Currently I am writing the entire contents of the 
POST from verisign to the ZODB however I have a problem that some of these 
POSTs are not being recorded because an error occurs later in the 
transaction.


What I would like to do is isolate this recording from everything else. So 
that no matter what other error is raised that part will commit so I have a 
record of the conversation later.


Currently I can put the logging step as the very first step in the 
conversation with verisign and call get_transaction().commit() (I am 
currently using zope 2.7 and working on the migration to zope 2.9)


What would be the best way to deal with this problem? Should I just do a 
commit of the transaction as the very first step so that part is written and 
then zope will start a new transaction for the rest of the stuff done? Should 
I somehow tell zope to run a certain function as its own transaction? Also 
when I switch over to zope 2.9 how will these things need to be changed?


The transaction.commit() others suggested is what I would do too. But be 
aware that if the second part of your transaction provokes a 
ConflictError (which may happen in the normal course of events), your 
whole request will be retried, including reinterpreting the POSTed data 
(which the request always saves anyway) and writing to your OOBTree etc.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope-dev] Re: default view

[Florent Guillaume]

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 RD
+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...

[Florent Guillaume]

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 RD
+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] Re: Performance hit for DeadlockDebugger?

[Florent Guillaume]

Chris Withers wrote:
Is there any performance hit for having DeadlockDebugger installed and 
enabled all the time on a production zope instance?


The only performance hit is an added
  if uri == dump_url:
per request, which is totally negligible.

DeadlockDebugger has been designed to stay enabled in production, which 
is why I added this whole secret password stuff.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope-dev] Re: default view

[Florent Guillaume]

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:

 browser:defaultView
 for=Products.Five.tests.testing.simplecontent.IIndexSimpleContent
 name=index_html
 /

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. browser:defaultView ... name=@@index.html /??? That doesn't
sound right.

Philipp




--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+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

[Florent Guillaume]

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 RD
+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]

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 RD
+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

[Florent Guillaume]

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 RD
+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]

Florent Guillaume wrote:

So here's a proposal: how about having the following order:
- __bobo_traverse__
- unacquired attribute
- zope 3 views
- acquired attributes


Attached is the current diff I'm working with (for Zope 2.10).
Please review the unit test (which pass as is), to check if you agree 
with the semantics.


I've decided that if you traverse .../foo/@@something, then only the 
zope 3 views will be consulted and never an attribute. I hope everyone 
agrees with that.


The remaining important question is: if a *default* view is specified 
using the zope 3 mechanism, should we always treat it as a zope 3 view, 
and refuse to lookup an attribute with that name?


Currently the traverse code is not completely coherent with respect to 
that, there's a NotFound in the tests I added which isn't coherent with 
the rest. So we should decide on one semantic.


To explicit the question, if you have:

browser:defaultView name=myview for=.IFoo/

and the publisher decides it has to use the default view (when 
.../foo/ is traversed), should it try to lookup myview as an 
attribute? Or should only the zope 3 view be looked up? I'd be inclined 
to not use attributes, after all that's zope 3 directives we're talking 
about.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+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.interface.implements(IDummy)
+def __init__(self, name):
+self.name = name
+
+class DummyObjectBasicZ3WithAttr(DummyObjectBasicZ3):
+def meth(self):
+doc
+return 'meth on %s' % self.name
+def methonly(self

[Zope-dev] Re: Time-based releases a good idea?

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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] Re: filter messages at startup

[Florent Guillaume]

Indeed they are logging.getLogger(Init) calls (from App/ 
class_init.py).

Why change that? They're perfectly fine in the event log.

Florent

On 13 Jun 2006, at 23:08, Chris McDonough wrote:




Not out of the box.


Egads, I think you're right.  These aren't actual warnings, are  
they?  They're log calls.  That should be changed.


- C


[EMAIL PROTECTED] tests]# /zope/test/bin/zopectl debug
Starting debugger (the name app is bound to the top-level Zope  
object)

2006-06-13 13:48:34 WARNING Init Class
Products.CMFCore.PortalContent.PortalContent has a security  
declaration for

nonexistent method 'manage_FTPget'
2006-06-13 13:48:34 WARNING Init Class
Products.CMFCore.PortalContent.PortalContent has a security  
declaration for

nonexistent method 'manage_FTPget'



--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]


___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope-dev] OFS.Application deprecations for Zope 2.10

[Florent Guillaume]

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 RD
+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?

[Florent Guillaume]

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 RD
+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?

[Florent Guillaume]

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 RD
+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:

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

In current Zope 2.10, when you have:

  page
  name=thepage
  for=.IFoo
  class=.view.FooView
  attribute=thepage
  permission=zope2.View
  /
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:

  browser:defaultView
  name=thepage
  for=.IFoo
  /

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 RD
+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-Checkins] SVN: Zope/branches/2.10/ Acquisition wrappers now correctly proxy __contains__.

[Florent Guillaume]

Log message for revision 68458:
  Acquisition wrappers now correctly proxy __contains__.
  
  

Changed:
  U   Zope/branches/2.10/doc/CHANGES.txt
  U   Zope/branches/2.10/lib/python/Acquisition/_Acquisition.c
  U   Zope/branches/2.10/lib/python/Acquisition/tests.py

-=-
Modified: Zope/branches/2.10/doc/CHANGES.txt
===
--- Zope/branches/2.10/doc/CHANGES.txt  2006-06-02 11:03:06 UTC (rev 68457)
+++ Zope/branches/2.10/doc/CHANGES.txt  2006-06-02 14:24:46 UTC (rev 68458)
@@ -14,6 +14,12 @@
  to the rules for such a type laid out in the Python docs:
  http://docs.python.org/api/supporting-cycle-detection.html
 
+  After Zope 2.10 beta 1
+
+Bugs Fixed
+
+  - Acquisition wrappers now correctly proxy __contains__.
+
   Zope 2.10 beta 1 (2006/05/30)
 
 Restructuring

Modified: Zope/branches/2.10/lib/python/Acquisition/_Acquisition.c
===
--- Zope/branches/2.10/lib/python/Acquisition/_Acquisition.c2006-06-02 
11:03:06 UTC (rev 68457)
+++ Zope/branches/2.10/lib/python/Acquisition/_Acquisition.c2006-06-02 
14:24:46 UTC (rev 68458)
@@ -37,7 +37,7 @@
   *py__pos__, *py__abs__, *py__nonzero__, *py__invert__, *py__int__,
   *py__long__, *py__float__, *py__oct__, *py__hex__,
   *py__getitem__, *py__setitem__, *py__delitem__,
-  *py__getslice__, *py__setslice__, *py__delslice__,
+  *py__getslice__, *py__setslice__, *py__delslice__,  *py__contains__,
   *py__len__, *py__of__, *py__call__, *py__repr__, *py__str__, *py__cmp__;
 
 static PyObject *Acquired=0;
@@ -75,6 +75,7 @@
   INIT_PY_NAME(__getslice__);
   INIT_PY_NAME(__setslice__);
   INIT_PY_NAME(__delslice__);
+  INIT_PY_NAME(__contains__);
   INIT_PY_NAME(__len__);
   INIT_PY_NAME(__of__);
   INIT_PY_NAME(__call__);
@@ -804,6 +805,18 @@
   return 0;
 }
 
+static int
+Wrapper_contains(Wrapper *self, PyObject *v)
+{
+  long c;
+
+  UNLESS(v=CallMethodO(OBJECT(self),py__contains__,Build((O), v) ,NULL))
+return -1;
+  c = PyInt_AsLong(v);
+  Py_DECREF(v);
+  return c;
+}
+
 static PySequenceMethods Wrapper_as_sequence = {
(inquiry)Wrapper_length,/*sq_length*/
(binaryfunc)Wrapper_add,/*sq_concat*/
@@ -812,6 +825,7 @@
(intintargfunc)Wrapper_slice,   /*sq_slice*/
(intobjargproc)Wrapper_ass_item,/*sq_ass_item*/
(intintobjargproc)Wrapper_ass_slice,/*sq_ass_slice*/
+   (objobjproc)Wrapper_contains,   /*sq_contains*/
 };
 
 /* -- */

Modified: Zope/branches/2.10/lib/python/Acquisition/tests.py
===
--- Zope/branches/2.10/lib/python/Acquisition/tests.py  2006-06-02 11:03:06 UTC 
(rev 68457)
+++ Zope/branches/2.10/lib/python/Acquisition/tests.py  2006-06-02 14:24:46 UTC 
(rev 68458)
@@ -1620,8 +1620,50 @@
 
 
 
-
+def test_proxying():
+Make sure that recent python slots are proxied.
 
+ import Acquisition
+ class Impl(Acquisition.Implicit):
+... pass
+
+ class C(Acquisition.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 naked class behaves like this:
+
+ c = C()
+ 3 in c
+contains 3
+False
+ 5 in c
+contains 5
+True
+
+Let's put c in the context of i:
+
+ i = Impl()
+ i.c = c
+
+Now check that __contains__ is properly used:
+
+ 3 in i.c # c.__of__(i)
+contains 3
+False
+ 5 in i.c
+contains 5
+True
+
+
+
+
 import unittest
 from zope.testing.doctest import DocTestSuite
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/doc/CHANGES.txt Sync formatting with trunk.

[Florent Guillaume]

Log message for revision 68460:
  Sync formatting with trunk.
  

Changed:
  U   Zope/branches/2.10/doc/CHANGES.txt

-=-
Modified: Zope/branches/2.10/doc/CHANGES.txt
===
--- Zope/branches/2.10/doc/CHANGES.txt  2006-06-02 14:34:52 UTC (rev 68459)
+++ Zope/branches/2.10/doc/CHANGES.txt  2006-06-02 14:38:06 UTC (rev 68460)
@@ -14,13 +14,13 @@
  to the rules for such a type laid out in the Python docs:
  http://docs.python.org/api/supporting-cycle-detection.html
 
-  After Zope 2.10 beta 1
+  Zope 2.10.0 beta 2 (unreleased)
 
 Bugs Fixed
 
   - Acquisition wrappers now correctly proxy __contains__.
 
-  Zope 2.10 beta 1 (2006/05/30)
+  Zope 2.10.0 beta 1 (2006/05/30)
 
 Restructuring
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PageTemplates/ Empty TALES path expressions are allowed in Zope 2.

[Florent Guillaume]

Log message for revision 68461:
  Empty TALES path expressions are allowed in Zope 2.
  http://www.zope.org/Collectors/Zope/2118
  

Changed:
  U   Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py
  U   
Zope/branches/2.10/lib/python/Products/PageTemplates/tests/testExpressions.py

-=-
Modified: Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py
===
--- Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py 
2006-06-02 14:38:06 UTC (rev 68460)
+++ Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py 
2006-06-02 15:02:15 UTC (rev 68461)
@@ -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/branches/2.10/lib/python/Products/PageTemplates/tests/testExpressions.py
===
--- 
Zope/branches/2.10/lib/python/Products/PageTemplates/tests/testExpressions.py   
2006-06-02 14:38:06 UTC (rev 68460)
+++ 
Zope/branches/2.10/lib/python/Products/PageTemplates/tests/testExpressions.py   
2006-06-02 15:02:15 UTC (rev 68461)
@@ -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

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PageTemplates/ Merged r68461 from 2.10 branch:

[Florent Guillaume]

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

[Zope-dev] Re: __contains__ and acquisition problem?

[Florent Guillaume]

Ok I fixed this for Zope 2.10 and trunk:

http://svn.zope.org/?view=revrev=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 RD
+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.

[Florent Guillaume]

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=revrev=68461

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+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-Checkins] SVN: Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py Removed a warning at Zope startup.

[Florent Guillaume]

Log message for revision 68427:
  Removed a warning at Zope startup.
  

Changed:
  U   Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py

-=-
Modified: Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py 2006-06-01 
09:25:43 UTC (rev 68426)
+++ Zope/branches/2.10/lib/python/Products/ZCatalog/ZCatalog.py 2006-06-01 
10:36:10 UTC (rev 68427)
@@ -37,7 +37,6 @@
 from Products.PluginIndexes.common.PluggableIndex \
  import PluggableIndexInterface
 from Products.PluginIndexes.interfaces import IPluggableIndex
-from Products.PluginIndexes.TextIndex import Splitter
 from zope.interface import implements
 
 from Catalog import Catalog, CatalogError
@@ -508,9 +507,12 @@
 '?manage_tabs_message=Reindexing%20Performed')
 
 
+# BBB: will be removed in Zope 2.12 (like TextIndex itself)
 security.declareProtected(manage_zcatalog_entries, 'availableSplitters')
 def availableSplitters(self):
  splitter we can add 
+# This import will trigger a deprecation warning about TextIndex
+from Products.PluginIndexes.TextIndex import Splitter
 return Splitter.availableSplitters
 
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py Merged r68427 from 2.10 branch:

[Florent Guillaume]

Log message for revision 68428:
  Merged r68427 from 2.10 branch:
  Removed a warning at Zope startup.
  
  

Changed:
  U   Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py

-=-
Modified: Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py
===
--- Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py 2006-06-01 10:36:10 UTC 
(rev 68427)
+++ Zope/trunk/lib/python/Products/ZCatalog/ZCatalog.py 2006-06-01 10:40:02 UTC 
(rev 68428)
@@ -37,7 +37,6 @@
 from Products.PluginIndexes.common.PluggableIndex \
  import PluggableIndexInterface
 from Products.PluginIndexes.interfaces import IPluggableIndex
-from Products.PluginIndexes.TextIndex import Splitter
 from zope.interface import implements
 
 from Catalog import Catalog, CatalogError
@@ -508,9 +507,12 @@
 '?manage_tabs_message=Reindexing%20Performed')
 
 
+# BBB: will be removed in Zope 2.12 (like TextIndex itself)
 security.declareProtected(manage_zcatalog_entries, 'availableSplitters')
 def availableSplitters(self):
  splitter we can add 
+# This import will trigger a deprecation warning about TextIndex
+from Products.PluginIndexes.TextIndex import Splitter
 return Splitter.availableSplitters
 
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py Removed a warning at Zope startup.

[Florent Guillaume]

Log message for revision 68430:
  Removed a warning at Zope startup.
  

Changed:
  U   Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py

-=-
Modified: Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py
===
--- Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py
2006-06-01 10:54:18 UTC (rev 68429)
+++ Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py
2006-06-01 11:48:09 UTC (rev 68430)
@@ -16,13 +16,21 @@
 import common.UnIndexas UnIndex
 
 import PathIndex.PathIndex
-import TextIndex.TextIndex
 import FieldIndex.FieldIndex
 import KeywordIndex.KeywordIndex
 import TopicIndex.TopicIndex
 import DateIndex.DateIndex
 import DateRangeIndex.DateRangeIndex
 
+# BBB: TextIndex is deprecated but we don't want the warning to appear here
+import warnings
+warnings.filterwarnings('ignore', message='^Using TextIndex', append=1)
+try:
+import TextIndex.TextIndex
+finally:
+del warnings.filters[-1]
+del __warningregistry__
+
 _indexes =  ('TextIndex',
  'KeywordIndex',
  'FieldIndex',

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PluginIndexes/__init__.py Removed a warning at Zope startup.

[Florent Guillaume]

Log message for revision 68431:
  Removed a warning at Zope startup.

Changed:
  U   Zope/trunk/lib/python/Products/PluginIndexes/__init__.py

-=-
Modified: Zope/trunk/lib/python/Products/PluginIndexes/__init__.py
===
--- Zope/trunk/lib/python/Products/PluginIndexes/__init__.py2006-06-01 
11:48:09 UTC (rev 68430)
+++ Zope/trunk/lib/python/Products/PluginIndexes/__init__.py2006-06-01 
11:50:02 UTC (rev 68431)
@@ -16,13 +16,21 @@
 import common.UnIndexas UnIndex
 
 import PathIndex.PathIndex
-import TextIndex.TextIndex
 import FieldIndex.FieldIndex
 import KeywordIndex.KeywordIndex
 import TopicIndex.TopicIndex
 import DateIndex.DateIndex
 import DateRangeIndex.DateRangeIndex
 
+# BBB: TextIndex is deprecated but we don't want the warning to appear here
+import warnings
+warnings.filterwarnings('ignore', message='^Using TextIndex', append=1)
+try:
+import TextIndex.TextIndex
+finally:
+del warnings.filters[-1]
+del __warningregistry__
+
 _indexes =  ('TextIndex',
  'KeywordIndex',
  'FieldIndex',

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py Removed a warning at Zope startup.

[Florent Guillaume]

Log message for revision 68432:
  Removed a warning at Zope startup.
  

Changed:
  U   Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py

-=-
Modified: Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py
===
--- Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py 2006-06-01 
11:50:02 UTC (rev 68431)
+++ Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py 2006-06-01 
11:52:56 UTC (rev 68432)
@@ -15,8 +15,16 @@
 
 import ZCatalog, CatalogAwareness, CatalogPathAwareness
 from Products.PluginIndexes.TextIndex import Vocabulary
-from ZClasses import createZClassForBase
 
+# BBB: ZClasses are deprecated but we don't want the warning to appear here
+import warnings
+warnings.filterwarnings('ignore', message='^ZClasses', append=1)
+try:
+from ZClasses import createZClassForBase
+finally:
+del warnings.filters[-1]
+del __warningregistry__
+
 createZClassForBase( ZCatalog.ZCatalog , globals()
, 'ZCatalogBase', 'ZCatalog' )
 createZClassForBase( CatalogAwareness.CatalogAware, globals()

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/ZCatalog/__init__.py Removed a warning at Zope startup.

[Florent Guillaume]

Log message for revision 68433:
  Removed a warning at Zope startup.

Changed:
  U   Zope/trunk/lib/python/Products/ZCatalog/__init__.py

-=-
Modified: Zope/trunk/lib/python/Products/ZCatalog/__init__.py
===
--- Zope/trunk/lib/python/Products/ZCatalog/__init__.py 2006-06-01 11:52:56 UTC 
(rev 68432)
+++ Zope/trunk/lib/python/Products/ZCatalog/__init__.py 2006-06-01 11:53:33 UTC 
(rev 68433)
@@ -15,8 +15,16 @@
 
 import ZCatalog, CatalogAwareness, CatalogPathAwareness
 from Products.PluginIndexes.TextIndex import Vocabulary
-from ZClasses import createZClassForBase
 
+# BBB: ZClasses are deprecated but we don't want the warning to appear here
+import warnings
+warnings.filterwarnings('ignore', message='^ZClasses', append=1)
+try:
+from ZClasses import createZClassForBase
+finally:
+del warnings.filters[-1]
+del __warningregistry__
+
 createZClassForBase( ZCatalog.ZCatalog , globals()
, 'ZCatalogBase', 'ZCatalog' )
 createZClassForBase( CatalogAwareness.CatalogAware, globals()

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py More robust.

[Florent Guillaume]

Log message for revision 68434:
  More robust.
  

Changed:
  U   Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py

-=-
Modified: Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py
===
--- Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py 2006-06-01 
11:53:33 UTC (rev 68433)
+++ Zope/branches/2.10/lib/python/Products/ZCatalog/__init__.py 2006-06-01 
11:56:03 UTC (rev 68434)
@@ -23,7 +23,10 @@
 from ZClasses import createZClassForBase
 finally:
 del warnings.filters[-1]
-del __warningregistry__
+try:
+del __warningregistry__
+except NameError:
+pass
 
 createZClassForBase( ZCatalog.ZCatalog , globals()
, 'ZCatalogBase', 'ZCatalog' )

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/ZCatalog/__init__.py More robust.

[Florent Guillaume]

Log message for revision 68435:
  More robust.

Changed:
  U   Zope/trunk/lib/python/Products/ZCatalog/__init__.py

-=-
Modified: Zope/trunk/lib/python/Products/ZCatalog/__init__.py
===
--- Zope/trunk/lib/python/Products/ZCatalog/__init__.py 2006-06-01 11:56:03 UTC 
(rev 68434)
+++ Zope/trunk/lib/python/Products/ZCatalog/__init__.py 2006-06-01 11:56:36 UTC 
(rev 68435)
@@ -23,7 +23,10 @@
 from ZClasses import createZClassForBase
 finally:
 del warnings.filters[-1]
-del __warningregistry__
+try:
+del __warningregistry__
+except NameError:
+pass
 
 createZClassForBase( ZCatalog.ZCatalog , globals()
, 'ZCatalogBase', 'ZCatalog' )

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py More robust.

[Florent Guillaume]

Log message for revision 68436:
  More robust.
  

Changed:
  U   Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py

-=-
Modified: Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py
===
--- Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py
2006-06-01 11:56:36 UTC (rev 68435)
+++ Zope/branches/2.10/lib/python/Products/PluginIndexes/__init__.py
2006-06-01 11:56:50 UTC (rev 68436)
@@ -29,7 +29,10 @@
 import TextIndex.TextIndex
 finally:
 del warnings.filters[-1]
-del __warningregistry__
+try:
+del __warningregistry__
+except NameError:
+pass
 
 _indexes =  ('TextIndex',
  'KeywordIndex',

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PluginIndexes/__init__.py More robust.

[Florent Guillaume]

Log message for revision 68437:
  More robust.

Changed:
  U   Zope/trunk/lib/python/Products/PluginIndexes/__init__.py

-=-
Modified: Zope/trunk/lib/python/Products/PluginIndexes/__init__.py
===
--- Zope/trunk/lib/python/Products/PluginIndexes/__init__.py2006-06-01 
11:56:50 UTC (rev 68436)
+++ Zope/trunk/lib/python/Products/PluginIndexes/__init__.py2006-06-01 
11:57:17 UTC (rev 68437)
@@ -29,7 +29,10 @@
 import TextIndex.TextIndex
 finally:
 del warnings.filters[-1]
-del __warningregistry__
+try:
+del __warningregistry__
+except NameError:
+pass
 
 _indexes =  ('TextIndex',
  'KeywordIndex',

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/App/Product.py Removed a warning at Zope startup.

[Florent Guillaume]

Log message for revision 68438:
  Removed a warning at Zope startup.
  

Changed:
  U   Zope/branches/2.10/lib/python/App/Product.py

-=-
Modified: Zope/branches/2.10/lib/python/App/Product.py
===
--- Zope/branches/2.10/lib/python/App/Product.py2006-06-01 11:57:17 UTC 
(rev 68437)
+++ Zope/branches/2.10/lib/python/App/Product.py2006-06-01 11:58:47 UTC 
(rev 68438)
@@ -42,7 +42,7 @@
 
 import Globals, OFS.Folder, OFS.SimpleItem,  Acquisition, Products
 from Globals import InitializeClass
-import ZClasses, AccessControl.Owned
+import AccessControl.Owned
 from OFS.Folder import Folder
 from HelpSys.HelpSys import ProductHelp
 from AccessControl import Unauthorized
@@ -53,6 +53,17 @@
 import RefreshFuncs
 from App.config import getConfiguration
 
+# BBB: ZClasses are deprecated but we don't want the warning to appear here
+import warnings
+warnings.filterwarnings('ignore', message='^ZClasses', append=1)
+try:
+import ZClasses
+finally:
+del warnings.filters[-1]
+try:
+del __warningregistry__
+except NameError:
+pass
 
 class ProductFolder(Folder):
 Manage a collection of Products

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/App/Product.py Removed a warning at Zope startup.

[Florent Guillaume]

Log message for revision 68439:
  Removed a warning at Zope startup.

Changed:
  U   Zope/trunk/lib/python/App/Product.py

-=-
Modified: Zope/trunk/lib/python/App/Product.py
===
--- Zope/trunk/lib/python/App/Product.py2006-06-01 11:58:47 UTC (rev 
68438)
+++ Zope/trunk/lib/python/App/Product.py2006-06-01 11:59:22 UTC (rev 
68439)
@@ -42,7 +42,7 @@
 
 import Globals, OFS.Folder, OFS.SimpleItem,  Acquisition, Products
 from Globals import InitializeClass
-import ZClasses, AccessControl.Owned
+import AccessControl.Owned
 from OFS.Folder import Folder
 from HelpSys.HelpSys import ProductHelp
 from AccessControl import Unauthorized
@@ -53,6 +53,17 @@
 import RefreshFuncs
 from App.config import getConfiguration
 
+# BBB: ZClasses are deprecated but we don't want the warning to appear here
+import warnings
+warnings.filterwarnings('ignore', message='^ZClasses', append=1)
+try:
+import ZClasses
+finally:
+del warnings.filters[-1]
+try:
+del __warningregistry__
+except NameError:
+pass
 
 class ProductFolder(Folder):
 Manage a collection of Products

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/Products/ZGadflyDA/__init__.py Don't warn when the ZGadflyDA is imported by Zope startup code.

[Florent Guillaume]

Log message for revision 68440:
  Don't warn when the ZGadflyDA is imported by Zope startup code.
  

Changed:
  U   Zope/branches/2.10/lib/python/Products/ZGadflyDA/__init__.py

-=-
Modified: Zope/branches/2.10/lib/python/Products/ZGadflyDA/__init__.py
===
--- Zope/branches/2.10/lib/python/Products/ZGadflyDA/__init__.py
2006-06-01 11:59:22 UTC (rev 68439)
+++ Zope/branches/2.10/lib/python/Products/ZGadflyDA/__init__.py
2006-06-01 12:17:15 UTC (rev 68440)
@@ -15,11 +15,14 @@
 $Id$
 
 
-import warnings
-warnings.warn('Using Gadfly and ZGadflyDA is deprecated. The module will be '
-  'removed in Zope 2.11)', 
-  DeprecationWarning,
-  stacklevel=2) 
+# Don't warn when the product is imported by the startup code
+import sys
+if sys._getframe(1).f_code.co_name != 'import_product': # OFS.Application
+import warnings
+warnings.warn('Using Gadfly and ZGadflyDA is deprecated. '
+  'The module will be removed in Zope 2.11)',
+  DeprecationWarning,
+  stacklevel=2)
 
 import Globals, os
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/ Make python security policy work with a boolean __aatus__

[Florent Guillaume]

Log message for revision 68444:
  Make python security policy work with a boolean __aatus__

Changed:
  U   Zope/branches/2.10/lib/python/AccessControl/ImplPython.py
  U   
Zope/branches/2.10/lib/python/AccessControl/tests/testZopeSecurityPolicy.py
  U   Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py

-=-
Modified: Zope/branches/2.10/lib/python/AccessControl/ImplPython.py
===
--- Zope/branches/2.10/lib/python/AccessControl/ImplPython.py   2006-06-01 
14:18:32 UTC (rev 68443)
+++ Zope/branches/2.10/lib/python/AccessControl/ImplPython.py   2006-06-01 
14:44:13 UTC (rev 68444)
@@ -318,7 +318,7 @@
 
 if p is not None:
 tp = p.__class__
-if tp is not int:
+if tp is not int and tp is not bool:
 if tp is dict:
 if isinstance(name, basestring):
 p = p.get(name)

Modified: 
Zope/branches/2.10/lib/python/AccessControl/tests/testZopeSecurityPolicy.py
===
--- Zope/branches/2.10/lib/python/AccessControl/tests/testZopeSecurityPolicy.py 
2006-06-01 14:18:32 UTC (rev 68443)
+++ Zope/branches/2.10/lib/python/AccessControl/tests/testZopeSecurityPolicy.py 
2006-06-01 14:44:13 UTC (rev 68444)
@@ -113,6 +113,11 @@
 __allow_access_to_unprotected_subobjects__ = 1
 
 
+class UnprotectedSimpleItemBool (SimpleItemish):
+
+__allow_access_to_unprotected_subobjects__ = True
+
+
 class OwnedSimpleItem(UnprotectedSimpleItem):
 def getOwner(self, info=0):
 if info:
@@ -159,6 +164,7 @@
 a = App()
 self.a = a
 a.item = UnprotectedSimpleItem()
+a.itemb = UnprotectedSimpleItemBool()
 self.item = a.item
 a.r_item = RestrictedSimpleItem()
 a.item1 = PartlyProtectedSimpleItem1()
@@ -237,11 +243,13 @@
 
 def testAccessToUnprotectedSubobjects(self):
 item = self.item
+itemb = self.a.itemb
 r_item = self.a.r_item
 item1 = self.a.item1
 item2 = self.a.item2
 item3 = self.a.item3
 self.assertPolicyAllows(item,  'public_prop')
+self.assertPolicyAllows(itemb, 'public_prop')
 self.assertPolicyDenies(r_item,'public_prop')
 self.assertPolicyAllows(item1, 'public_prop')
 self.assertPolicyAllows(item2, 'public_prop')

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:18:32 UTC (rev 68443)
+++ Zope/branches/2.10/lib/python/Products/PageTemplates/Expressions.py 
2006-06-01 14:44:13 UTC (rev 68444)
@@ -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)
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/AccessControl/ Make python security policy work with a boolean __aatus__

[Florent Guillaume]

Log message for revision 68446:
  Make python security policy work with a boolean __aatus__

Changed:
  U   Zope/trunk/lib/python/AccessControl/ImplPython.py
  U   Zope/trunk/lib/python/AccessControl/tests/testZopeSecurityPolicy.py

-=-
Modified: Zope/trunk/lib/python/AccessControl/ImplPython.py
===
--- Zope/trunk/lib/python/AccessControl/ImplPython.py   2006-06-01 14:46:17 UTC 
(rev 68445)
+++ Zope/trunk/lib/python/AccessControl/ImplPython.py   2006-06-01 14:48:15 UTC 
(rev 68446)
@@ -318,7 +318,7 @@
 
 if p is not None:
 tp = p.__class__
-if tp is not int:
+if tp is not int and tp is not bool:
 if tp is dict:
 if isinstance(name, basestring):
 p = p.get(name)

Modified: Zope/trunk/lib/python/AccessControl/tests/testZopeSecurityPolicy.py
===
--- Zope/trunk/lib/python/AccessControl/tests/testZopeSecurityPolicy.py 
2006-06-01 14:46:17 UTC (rev 68445)
+++ Zope/trunk/lib/python/AccessControl/tests/testZopeSecurityPolicy.py 
2006-06-01 14:48:15 UTC (rev 68446)
@@ -113,6 +113,11 @@
 __allow_access_to_unprotected_subobjects__ = 1
 
 
+class UnprotectedSimpleItemBool (SimpleItemish):
+
+__allow_access_to_unprotected_subobjects__ = True
+
+
 class OwnedSimpleItem(UnprotectedSimpleItem):
 def getOwner(self, info=0):
 if info:
@@ -159,6 +164,7 @@
 a = App()
 self.a = a
 a.item = UnprotectedSimpleItem()
+a.itemb = UnprotectedSimpleItemBool()
 self.item = a.item
 a.r_item = RestrictedSimpleItem()
 a.item1 = PartlyProtectedSimpleItem1()
@@ -237,11 +243,13 @@
 
 def testAccessToUnprotectedSubobjects(self):
 item = self.item
+itemb = self.a.itemb
 r_item = self.a.r_item
 item1 = self.a.item1
 item2 = self.a.item2
 item3 = self.a.item3
 self.assertPolicyAllows(item,  'public_prop')
+self.assertPolicyAllows(itemb, 'public_prop')
 self.assertPolicyDenies(r_item,'public_prop')
 self.assertPolicyAllows(item1, 'public_prop')
 self.assertPolicyAllows(item2, 'public_prop')

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/AccessControl/ Make python security policy work with a boolean __aatus__

[Florent Guillaume]

Log message for revision 68447:
  Make python security policy work with a boolean __aatus__

Changed:
  U   Zope/branches/2.9/lib/python/AccessControl/ImplPython.py
  U   Zope/branches/2.9/lib/python/AccessControl/tests/testZopeSecurityPolicy.py

-=-
Modified: Zope/branches/2.9/lib/python/AccessControl/ImplPython.py
===
--- Zope/branches/2.9/lib/python/AccessControl/ImplPython.py2006-06-01 
14:48:15 UTC (rev 68446)
+++ Zope/branches/2.9/lib/python/AccessControl/ImplPython.py2006-06-01 
16:08:52 UTC (rev 68447)
@@ -317,7 +317,7 @@
 
 if p is not None:
 tp = p.__class__
-if tp is not int:
+if tp is not int and tp is not bool:
 if tp is dict:
 if isinstance(name, basestring):
 p = p.get(name)

Modified: 
Zope/branches/2.9/lib/python/AccessControl/tests/testZopeSecurityPolicy.py
===
--- Zope/branches/2.9/lib/python/AccessControl/tests/testZopeSecurityPolicy.py  
2006-06-01 14:48:15 UTC (rev 68446)
+++ Zope/branches/2.9/lib/python/AccessControl/tests/testZopeSecurityPolicy.py  
2006-06-01 16:08:52 UTC (rev 68447)
@@ -113,6 +113,11 @@
 __allow_access_to_unprotected_subobjects__ = 1
 
 
+class UnprotectedSimpleItemBool (SimpleItemish):
+
+__allow_access_to_unprotected_subobjects__ = True
+
+
 class OwnedSimpleItem(UnprotectedSimpleItem):
 def getOwner(self, info=0):
 if info:
@@ -159,6 +164,7 @@
 a = App()
 self.a = a
 a.item = UnprotectedSimpleItem()
+a.itemb = UnprotectedSimpleItemBool()
 self.item = a.item
 a.r_item = RestrictedSimpleItem()
 a.item1 = PartlyProtectedSimpleItem1()
@@ -237,11 +243,13 @@
 
 def testAccessToUnprotectedSubobjects(self):
 item = self.item
+itemb = self.a.itemb
 r_item = self.a.r_item
 item1 = self.a.item1
 item2 = self.a.item2
 item3 = self.a.item3
 self.assertPolicyAllows(item,  'public_prop')
+self.assertPolicyAllows(itemb, 'public_prop')
 self.assertPolicyDenies(r_item,'public_prop')
 self.assertPolicyAllows(item1, 'public_prop')
 self.assertPolicyAllows(item2, 'public_prop')

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/branches/2.10/lib/python/AccessControl/ImplPython.py Use isinstance, like the C implementation.

[Florent Guillaume]

Log message for revision 68448:
  Use isinstance, like the C implementation.
  

Changed:
  U   Zope/branches/2.10/lib/python/AccessControl/ImplPython.py

-=-
Modified: Zope/branches/2.10/lib/python/AccessControl/ImplPython.py
===
--- Zope/branches/2.10/lib/python/AccessControl/ImplPython.py   2006-06-01 
16:08:52 UTC (rev 68447)
+++ Zope/branches/2.10/lib/python/AccessControl/ImplPython.py   2006-06-01 
16:29:40 UTC (rev 68448)
@@ -317,9 +317,8 @@
 None)
 
 if p is not None:
-tp = p.__class__
-if tp is not int and tp is not bool:
-if tp is dict:
+if not isinstance(p, int): # catches bool too
+if isinstance(p, dict):
 if isinstance(name, basestring):
 p = p.get(name)
 else:

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/AccessControl/ImplPython.py Use isinstance, like the C implementation.

[Florent Guillaume]

Log message for revision 68449:
  Use isinstance, like the C implementation.
  

Changed:
  U   Zope/trunk/lib/python/AccessControl/ImplPython.py

-=-
Modified: Zope/trunk/lib/python/AccessControl/ImplPython.py
===
--- Zope/trunk/lib/python/AccessControl/ImplPython.py   2006-06-01 16:29:40 UTC 
(rev 68448)
+++ Zope/trunk/lib/python/AccessControl/ImplPython.py   2006-06-01 16:30:15 UTC 
(rev 68449)
@@ -317,9 +317,8 @@
 None)
 
 if p is not None:
-tp = p.__class__
-if tp is not int and tp is not bool:
-if tp is dict:
+if not isinstance(p, int): # catches bool too
+if isinstance(p, dict):
 if isinstance(name, basestring):
 p = p.get(name)
 else:

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-dev] Zope 2.10 TALES repeat and 'item'

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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__

[Florent Guillaume]

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 RD
+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-Checkins] SVN: Zope/branches/2.10/lib/python/Products/PageTemplates/PageTemplateFile.py There must be no warning when __name__ is supplied.

[Florent Guillaume]

Log message for revision 68414:
  There must be no warning when __name__ is supplied.

Changed:
  U   Zope/branches/2.10/lib/python/Products/PageTemplates/PageTemplateFile.py

-=-
Modified: 
Zope/branches/2.10/lib/python/Products/PageTemplates/PageTemplateFile.py
===
--- Zope/branches/2.10/lib/python/Products/PageTemplates/PageTemplateFile.py
2006-05-31 17:36:17 UTC (rev 68413)
+++ Zope/branches/2.10/lib/python/Products/PageTemplates/PageTemplateFile.py
2006-05-31 17:59:21 UTC (rev 68414)
@@ -59,15 +59,13 @@
 _default_bindings = {'name_subpath': 'traverse_subpath'}
 
 def __init__(self, filename, _prefix=None, **kw):
-name = None
-if kw.has_key('__name__'):
-name = kw['__name__']
-del kw['__name__'] 
+name = kw.pop('__name__', None)
 
 basepath, ext = os.path.splitext(filename)
 
 if name:
 self.id = self.__name__ = name
+self._need__name__ = 0
 else:
 self.id = self.__name__ = os.path.basename(basepath)
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/Products/PageTemplates/PageTemplateFile.py Merged r68414 from 2.10 branch:

[Florent Guillaume]

Log message for revision 68415:
  Merged r68414 from 2.10 branch:
  There must be no warning when __name__ is supplied.
  

Changed:
  U   Zope/trunk/lib/python/Products/PageTemplates/PageTemplateFile.py

-=-
Modified: Zope/trunk/lib/python/Products/PageTemplates/PageTemplateFile.py
===
--- Zope/trunk/lib/python/Products/PageTemplates/PageTemplateFile.py
2006-05-31 17:59:21 UTC (rev 68414)
+++ Zope/trunk/lib/python/Products/PageTemplates/PageTemplateFile.py
2006-05-31 18:00:30 UTC (rev 68415)
@@ -59,15 +59,13 @@
 _default_bindings = {'name_subpath': 'traverse_subpath'}
 
 def __init__(self, filename, _prefix=None, **kw):
-name = None
-if kw.has_key('__name__'):
-name = kw['__name__']
-del kw['__name__'] 
+name = kw.pop('__name__', None)
 
 basepath, ext = os.path.splitext(filename)
 
 if name:
 self.id = self.__name__ = name
+self._need__name__ = 0
 else:
 self.id = self.__name__ = os.path.basename(basepath)
 

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/...

[Florent Guillaume]

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 RD
+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/...

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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] Re: ftp server deadlocking zope with DeadlockDebugger

[Florent Guillaume]

')
 File /home/www/Zope-2.8.5-0/Products/LinguaPlone/I18NBaseObject.py, 
line 150, in getTranslationLanguages

   return self.getTranslations().keys()
 File /home/www/Zope-2.8.5-0/Products/LinguaPlone/I18NBaseObject.py, 
line 176, in getTranslations

   return self.getCanonical().getTranslations()
 File /home/www/Zope-2.8.5-0/Products/LinguaPlone/I18NBaseObject.py, 
line 174, in getTranslations

   return result
 File /home/www/Zope-2.8.5-0/Products/Archetypes/Referenceable.py, 
line 93, in getBRefs

   return [ref.getSourceObject() for ref in refs]
 File /home/www/Zope-2.8.5-0/Products/Archetypes/ReferenceEngine.py, 
line 595, in getBackReferences

   return self._resolveBrains(brains)
 File /home/www/Zope-2.8.5-0/Products/Archetypes/ReferenceEngine.py, 
line 690, in _queryFor

   return brains
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/ZCatalog/ZCatalog.py, 
line 690, in searchResults

   return self._catalog.searchResults(REQUEST, used, **kw)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/ZCatalog/Catalog.py, 
line 733, in searchResults

   return self.search(args, sort_index, reverse, sort_limit, _merge)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/ZCatalog/Catalog.py, 
line 533, in search

   return LazyMap(self.__getitem__, rs, len(rs))
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/PluginIndexes/common/UnIndex.py, 
line 347, in _apply_index

   if record.keys==None: return None
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/PluginIndexes/common/util.py, 
line 70, in __init__

   return
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/ZCatalog/Catalog.py, 
line 771, in has_key

   except KeyError:


Thread 10 (GET /dirname/manage_FTPlist):
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/ZServer/PubCore/ZServerPublisher.py, 
line 23, in __init__

   response=response)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/ZPublisher/Publish.py, 
line 386, in publish_module

   environ, debug, request, response)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/ZPublisher/Publish.py, 
line 187, in publish_module_standard

   response = publish(request, module_name, after_list, debug=debug)
 File 
/home/www/Zope-2.8.5-0/Products/PlacelessTranslationService/PatchStringIO.py, 
line 51, in new_publish

   x = Publish.old_publish(request, module_name, after_list, debug)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/ZPublisher/Publish.py, 
line 104, in publish

   object=request.traverse(path, validated_hook=validated_hook)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/ZPublisher/BaseRequest.py, 
line 272, in traverse

   bpth(object, self)
 File /home/www/Zope-2.8.5-0/Products/LinguaPlone/I18NBaseObject.py, 
line 413, in __before_publishing_traverse__

   translation = self.getTranslation(cookie_lang)
 File /home/www/Zope-2.8.5-0/Products/LinguaPlone/I18NBaseObject.py, 
line 139, in getTranslation

   l = self.getTranslations().get(language, None)
 File /home/www/Zope-2.8.5-0/Products/LinguaPlone/I18NBaseObject.py, 
line 176, in getTranslations

   return self.getCanonical().getTranslations()
 File /home/www/Zope-2.8.5-0/Products/LinguaPlone/I18NBaseObject.py, 
line 168, in getTranslations

   for obj in self.getBRefs(config.RELATIONSHIP):
 File /home/www/Zope-2.8.5-0/Products/Archetypes/Referenceable.py, 
line 91, in getBRefs
   refs = tool.getBackReferences(self, relationship, 
targetObject=targetObject)
 File /home/www/Zope-2.8.5-0/Products/Archetypes/ReferenceEngine.py, 
line 594, in getBackReferences

   brains = self._queryFor(tid=sID, relationship=relationship, sid=tID)
 File /home/www/Zope-2.8.5-0/Products/Archetypes/ReferenceEngine.py, 
line 688, in _queryFor

   brains = self.searchResults(query, merge=merge)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/ZCatalog/ZCatalog.py, 
line 690, in searchResults

   return self._catalog.searchResults(REQUEST, used, **kw)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/ZCatalog/Catalog.py, 
line 733, in searchResults

   return self.search(args, sort_index, reverse, sort_limit, _merge)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/ZCatalog/Catalog.py, 
line 476, in search

   r = _apply_index(request)
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/PluginIndexes/common/UnIndex.py, 
line 372, in _apply_index

   if record.get('usage',None):
 File 
/usr/local/mypackages/Zope-2.8.5-final/lib/python/Products/PluginIndexes/common/util.py, 
line 133, in get

   def get(self,k,default_v=None):

___
Zope maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )




--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD

[Zope-dev] Re: request.debug needed for Zope 3 ZPT engine

[Florent Guillaume]

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 RD
+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.

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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?

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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] Re: zope unresponsive

[Florent Guillaume]

Try DeadlockDebugger.

Florent

Andy Altepeter wrote:

Hey All,

I'm experiencing hanging issues with my Zope-2.8.6+zeo setup/ RHEL 4. The 
hanging isn't categorized by 100% cpu usage. Actually, I had the same issues 
using 2.8.5, but I've upgraded since then.  Here's the situation:


I have one zeo client connected to a zeo server on the same box.  Apache sits 
in front, using RewriteRules to request data from zope.


After some time (could be 2 minutes or an hour), the zeo client stops 
responding.  Apparently this is called a deadlock or a spinning zope.


I've tried using gdb to attach to the zeo client pid, and use the recipe 
http://zopelabs.com/cookbook/1073504990 to print a traceback, but the call 
always aborted with SIGABORT. 

I've captured all of the requests sent to zope during an uptime window (via 
Z2.log), and using wget to replay the requests.  I've also pulled from 
apache's rewrite log all requests proxied to zope, thinking the Z2.log only 
writes finished requests.  I setup another zeo client (on the same box, 
different port) and used wget to replay these captures as well.  Just running 
these captures does not cause zope to hang.  In fact, I have not been able to 
cause zope to hang by replaying.  There doesn't seem to be any one url or 
sequence of urls that cause zope to hang.


I've tried reinstalling the zope instance, but that didn't help.

I've tried using requestprofiler.py to inspect the trace.log.  This shows a 
high number of hangs, but not on a url that actually triggers a spinning 
zope.


Basically, that's where I'm stuck.  Is there anything else I can try?  Am I 
missing something?


Thanks for the help,
Andy
___
Zope maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce

 http://mail.zope.org/mailman/listinfo/zope-dev )




--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope-dev] Re: [ANN] pythonproducts 1.0beta1 released

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 five:traversable.  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 RD
+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

[Florent Guillaume]

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 RD
+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()

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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()

[Florent Guillaume]

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 RD
+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] Re: CMFExternalFile and huge ZODB pickles

[Florent Guillaume]

Pawel Lewicki wrote:

Hi,
I have a problem with one Zope application and have no clue what's going 
on. The problem is with one ControlledPage that creates 
CMFExternalFiles. It seems that each file is somehow included in ZODB 
pickle so Data.fs grows very fast. Only packing helps. The side effect 
is that transaction takes quite a long time so conflicts are very common.
I tried to recreate the environment on the other machine and everything 
was fine despite the fact that I used all the same products. The only 
difference was that original app was running on Linux and I did it on 
Windows.

Any clues?
Products used:
- ExternalFile 1.2.0
- CMFExternalFile 0.5
- Plone 2.0.5
- Zope 2.7.6

BTW, how do you distinct read and write conflicts in event.log? I only have
INFO(0) ZODB conflict error at...


Read conflicts say ReadConflict somewhere. Write conflicts do not.
Probably only in recent Zopes though, I doubt 2.7 has that detail.

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: major problems placing authentication on an extranet site-security flaw?

[Florent Guillaume]

Michael Vartanyan wrote:
In the very beginning of my Zope career, I once shot myself in the 
foot with a very stupid thing... I kept it to myself then but if we are 
talking about Zope security settings and usability of the ZMI at the 
same time, perhaps it is an ideal place to raise this issue.


If you use the famous manage_access page with all the checkboxes to set 
permissions on an object, it then calls manage_changePermissions to 
using POST method to apply your settings. The result is that 
http://your_object_url/manage_changePermissions (without any parameters) 
stays in your browser visited url history. Now imagine what happens if 
you click this url by mistake being logged as someone with Change 
permissions permission.


I guess changing the form method to GET is not going to be liked by 
browsers that put additional restrictions on URL length. So I would 
propose to introduce a basic request sanity check in the 
manage_changePermissions itself. I cannot think of any use for resetting 
all permissions and acquisition for everyone, so the easiest way to do 
that is to simply check that at least something exists in the form:


...
   def manage_changePermissions(self, REQUEST):
   Change all permissions settings, called by management screen.
   
 if  len(REQUEST.form)2: raise ...
   self._isBeingUsedAsAMethod(REQUEST, 0)
   valid_roles=self.valid_roles()
   indexes=range(len(valid_roles))
   have=REQUEST.has_key
   permissions=self.ac_inherited_permissions(1)
   fails = []
...

or something like that.


Actually the proper way to do it, and for exactly the reasons you outlined 
above, is to always do a redirect to a result page url after a POST that 
has side effects. It's even mandated by the HTTP/HTML specs.


Florent


--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Method to return the properties of an object

[Florent Guillaume]

You could use any of a various set of introspection/debugging tools.

One of them is
http://svn.nuxeo.org/trac/pub/browser/ZMIntrospection/trunk/

There are others, like
http://www.zope.org/Members/shh/DocFinderEverywhere

Florent


George wrote:

Is there a method to return the properties of an object?

Sorry if it's sth obvious!*
*





___
Zope maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce

 http://mail.zope.org/mailman/listinfo/zope-dev )



--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: restricting permissions for direct access only

[Florent Guillaume]

Michael Shulman wrote:

Hi,

I am new to Zope, and so far I like it very much.  But I think I am
confused about how security works, or is supposed to work.
Specifically I want to know the following.

Is there a way in Zope to restrict permissions for direct access only
(i.e. calling an object through the web) but still allow indirect
access (i.e. executing an object that was called by another object
that was called through the web)?


Objects called by a URL have a REQUEST parameter. What I usually do is make 
the script accept an optional REQUEST=None, and if it's non-None then I 
raise Unauthorized.


Florent

  I have many Zope scripts but most

of them are only auxiliary functions; only a few are designed to be
accessed by a user through a URL.  I don't want users to be able to
call my auxiliary scripts directly, only the ones that are designed to
be published.  But changing the security settings on the auxiliary
scripts (e.g. removing View access from Anonymous role) prevents
anonymous users from executing them even indirectly, so the public
objects which depend on those auxiliary methods also stop working.

Feel free to tell me that I am misunderstanding the way security
works, or is supposed to work, in Zope, or that if this is something I
need to do I am designing my site incorrectly from the point of view
of Zope security (and if so, what is the correct way to design it?).

Thanks!!
Mike


--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope-dev] Re: Inhibit URL-traversal

[Florent Guillaume]

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 RD
+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

[Florent Guillaume]

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 RD
+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] Re: raw trace log format

[Florent Guillaume]

It's the size of the POST, and 0 for a GET. Basically the size of received 
data (appart from the request headers).


Florent

Dennis Allison wrote:
I gleened what I could from the requestrofiler code, but teh 
meaning of the desc field for I is not described in the comments.
A quick check of the code did not help either.  



On Thu, 2 Feb 2006, Tres Seaver wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dennis Allison wrote:
generally it's 


code id fromepoch desc

The desc field is

B   request (e.g. 'GET /')
I   ???
A   status_code bytes
E

The desc for E is normally empty.  The desc for I is usually 0 
or a small integer.  Google could not help me find a definition 
for the desc value associated with I.  Can someone assist?

I'd suggest looking at '$SOFTWARE_HOME/utilities/requestprofiler.py',
which is a tool for reporting against that log file.



--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: ZEO disconnects, Zope auto restarts (via zopectl)

[Florent Guillaume]

Dennis Allison wrote:
We are seeing spontaneous restarts of Zope with no indication in any of 
the standard Zope logs.  Looking at the ZEO log indicates that the 
restarts of Zope are due to a lost connection between Zope  ZEO but 
with no other information.  The logging level is set at the distribution 
default (INFO).


The restarts are a huge problem because session variables are not
persistent and so all of the user state they contain is lost on restart.
In our statful implementation, this is a major problem.  I want to adjust 
the configuration so that the Zope/ZEO connection is stable.
  
In our configuration, Zope and ZEO are linked via localhost on a

distinguished port.

I've Googled about looking for some infomation about tuning the ZEO/Zope 
interface, but have found little real information.   Some additional log

detail would be helpful.


Once established, connections between ZEO server and Zope should be totally 
stable. I'd investigate network or firewall problems, and I'd start by using 
a network trace to find out what's happening at the TCP and IP levels.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Product refreshing in Zope 2.9

[Florent Guillaume]

Peter Bengtsson wrote:

On 1/30/06, Andreas Jung wrote:

--On 30. Januar 2006 17:39:11 + Peter Bengtsson wrote:

It's not a strange product. It's quite simple in fact.
Not being able to refresh without restarting means that I can't use
Zope 2.9 for python product development.

Why is refresh a requirement for doing Zope development? I am doing Zope
development since five or six years and I have never done any development
using Refresh...so there must be something very special with your
development approach?!


Sorry. It's not a _requirement_. But without it I loose productivity.
(see my previous email on this topic with the human benchmark,
ValueErrors and lost SESSIONS).

I too have several years of zope programming beyond the ZMI and have
developed many products and refreshing is the only way I know to
quickly test changes.
Having to wait a few seconds for each test is not an option.

How do you solve this problem without refreshing? Or are you ready to
wait for the zope restart and avoid it by writing more unit tests?


Yes most people who are serious about their developments use unit tests and 
functional tests and non-regression tests. They start by coding tests and 
doctests about code they've not yet written.


In most cases when I develop, I don't go to the ZMI until quite late in the 
process. Going to the ZMI is not productive.


That's why I, like others in this thread, don't care about refresh.

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Product refreshing in Zope 2.9

[Florent Guillaume]

Peter Bengtsson wrote:

On 1/31/06, Jens Vagelpohl [EMAIL PROTECTED] wrote:

On 31 Jan 2006, at 12:02, Peter Bengtsson wrote:

That's why I, like others in this thread, don't care about refresh.


Like I mentioned elsewhere, with my setup, restarting zope is gravely
inferior to zope-restart for product development.

I'm happy to share my setup to Open Source but it's quite personal
so I'd have to spend as much time explaining it as I have spent
writing it.
Hmm... perhaps a screencast?

I don't think there is any need for that. The situation is pretty
simple: You have an itch, but no one cares enough to scratch it for
you. The only sane way forward is for you to scratch the itch yourself.


But that's what I'm doing!
Thanks to Dieter I've got som genuine technical help on what it might
be instead of just people saying that's not how I do it, give up

And I don't understand how Zope product refresh doesn't have a higher
attention priority when it's so useful.


Refresh works well in limited situations, but it *cannot work* if you have 
global registries or many interrelated modules.



As far as I know, it's the
only way to make changes to a zope2 product without having to restart
the server causing downtime and lost sessions.


Then use ZEO. And on a development server you can have the sessions in a 
shared ZEO filestorage.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: zserver-threads

[Florent Guillaume]

Dieter Maurer wrote:

Jens Vagelpohl wrote at 2006-1-31 15:07 +:

On 31 Jan 2006, at 15:01, Jake wrote:


http://plone.org/documentation/how-to/threads-vs-cache-size
That article contains little information to back up the conclusions,  
and some of it is patently wrong. Another case of hearsay and half- 
thruths being propagated by well-meaning but uninformed parties.


There is a convincing example (I think from Matt Kromer) what
happens to mean response time when the number of threads
is increased from 1 to 2:

  Assume you have 2 units of work. If you have a single
  thread, 1 unit is done, then the second. The
  mean response time is (1 + 2) / 2 = 1.5.

  Now assume you have two threads (but a single processor).
  Both threads work (quasi) parallel but have only half of the
  processor power. Both will take 2 time units to perform
  their unit of work. The mean response time is (2 + 2) / 2 = 2.


This is specious reasoning from a statistical point of view. You never 
have only two requests. To have a proper statistical evaluation, you 
need a theoretical model of the distribution of requests over time. This 
can be as simple as a request every t. Then you have a continuous flow 
of requests, and the two means become equal.


Just try it with 4 units of work and equivalent time distribution as in 
the original example:

- Case 1: (1+2+3+4)/4 = 2.5
- Case 2: (2+2+4+4)/4 = 3

If you generalize to n units of work, you'll get (the math is simple):
- Case 1: n(n+1)/2n = n/2+0.5
- Case 2: 4((n/2)(n/2+1)/2)/n = n/2+1

Which are equivalent to n/2 when n grows.

Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Security class attribute

[Florent Guillaume]

Peter Bengtsson wrote:

On 1/26/06, Brian Lloyd [EMAIL PROTECTED] wrote:

The ClassSecurityInfo is a convenience to provide a
halfway-sane spelling for a lot of ugliness under the
hood in setting up security.

IntializeClass (among other things) tells the CSI to
apply itself to the class to set everything up, then it
gets *removed* from the class.

I can't tell for sure from your code, but I suspect that
IntializeClass is being called on MyProduct *before* you
are doing your class augmentation -- if you can defer the
call until after you hack it, it should work.



No, I did the InitializeClass() *after* everything else.
So still no explaination. For what's going on.


That's because for all classes deriving from ExtensionClass there's a 
magical call (indirectly) to InitializeClass as soon as they are defined. 
That's one of the numerous things Jim pioneered with ExtensionClasses, at a 
time where metaclasses didn't exist.


Florent



--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Class instances changing address?

[Florent Guillaume]

Jeff Gentry wrote:

I'm running Zope 2.7.3 w/ python 2.4.1.  I'm in the process of developing
a FS based product as a primary class w/ many sub-classes.  I've been
experiencing a problem which I thought I had completely nixed but
apparently only partly so and now am out of ideas as to what might be the
source of the problem.

As background, the primary class (A) maintains a handle to an instance of
another class (B) which handles interaction w/ a psycopg db
controller.  Class A also will instantiate several instances of Class C
and as part of the construction will pass it the handle to class B.  So in
summary, A has a B and has 1:n C's, and C has a reference to B.  A  B
have physical representations in the ZMI, while instances of C are
'virtual'.


We say that A and B are persistent classes, while C is not.
You have to be aware that persistent classes have special needs, and using 
them has consequences. One being that, due to transactional behaviour, 
several versions of the same instance of an object may be present in the 
system, in different threads, for different requests. They'll have different 
addresses.


Also be aware that it doesn't make sense for a non-persistent class to refer 
to a persistent instance unless it knows that they can be thread-specific.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope-dev] Re: Deprecation process issues

[Florent Guillaume]

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 RD
+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-Checkins] SVN: Zope/branches/2.9/lib/python/ZClasses/ZClass.txt Fix temp_folder mounting problem.

[Florent Guillaume]

Log message for revision 41327:
  Fix temp_folder mounting problem.
  
  Othere tests don't pass though, maybe I think due to __implemented__ and
  __provides__ attributes in the persistentclass state.
  

Changed:
  U   Zope/branches/2.9/lib/python/ZClasses/ZClass.txt

-=-
Modified: Zope/branches/2.9/lib/python/ZClasses/ZClass.txt
===
--- Zope/branches/2.9/lib/python/ZClasses/ZClass.txt2006-01-16 15:10:30 UTC 
(rev 41326)
+++ Zope/branches/2.9/lib/python/ZClasses/ZClass.txt2006-01-16 16:38:25 UTC 
(rev 41327)
@@ -16,6 +16,8 @@
  from OFS.Application import Application
  app = Application()
  conn.root()['Application'] = app
+ from OFS.Folder import manage_addFolder
+ manage_addFolder(app, 'temp_folder')
  from OFS.Application import initialize
  initialize(app)
  app.manage_addFolder('sandbox')

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-Checkins] SVN: Zope/trunk/lib/python/ZClasses/ZClass.txt Fix temp_folder mounting problem.

[Florent Guillaume]

Log message for revision 41328:
  Fix temp_folder mounting problem.
  
  Othere tests don't pass though, maybe I think due to __implemented__ and
  __provides__ attributes in the persistentclass state.
  

Changed:
  U   Zope/trunk/lib/python/ZClasses/ZClass.txt

-=-
Modified: Zope/trunk/lib/python/ZClasses/ZClass.txt
===
--- Zope/trunk/lib/python/ZClasses/ZClass.txt   2006-01-16 16:38:25 UTC (rev 
41327)
+++ Zope/trunk/lib/python/ZClasses/ZClass.txt   2006-01-16 16:39:00 UTC (rev 
41328)
@@ -16,6 +16,8 @@
  from OFS.Application import Application
  app = Application()
  conn.root()['Application'] = app
+ from OFS.Folder import manage_addFolder
+ manage_addFolder(app, 'temp_folder')
  from OFS.Application import initialize
  initialize(app)
  app.manage_addFolder('sandbox')

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

[Zope-dev] Re: Zope tests: 6 OK, 2 Failed

[Florent Guillaume]

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, sigh.

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 RD
+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

[Florent Guillaume]

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 RD
+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-Checkins] SVN: Zope/branches/2.9/lib/python/Zope2/App/startup.py When a database is created by hand from a custom_zodb.py during

[Florent Guillaume]

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.
  

Changed:
  U   Zope/branches/2.9/lib/python/Zope2/App/startup.py

-=-
Modified: Zope/branches/2.9/lib/python/Zope2/App/startup.py
===
--- Zope/branches/2.9/lib/python/Zope2/App/startup.py   2006-01-13 16:26:04 UTC 
(rev 41302)
+++ Zope/branches/2.9/lib/python/Zope2/App/startup.py   2006-01-13 16:47:56 UTC 
(rev 41303)
@@ -45,28 +45,31 @@
 # Import products
 OFS.Application.import_products()
 
+configuration = getConfiguration()
+
 # Open the database
+dbtab = configuration.dbtab
 try:
 # Try to use custom storage
 try:
-m=imp.find_module('custom_zodb',[getConfiguration().testinghome])
+m=imp.find_module('custom_zodb',[configuration.testinghome])
 except:
-m=imp.find_module('custom_zodb',[getConfiguration().instancehome])
+m=imp.find_module('custom_zodb',[configuration.instancehome])
 except:
 # if there is no custom_zodb, use the config file specified databases
-configuration = getConfiguration()
-DB = configuration.dbtab.getDatabase('/', is_root=1)
-Globals.BobobaseName = DB.getName()
+DB = dbtab.getDatabase('/', is_root=1)
 else:
 m=imp.load_module('Zope2.custom_zodb', m[0], m[1], m[2])
+sys.modules['Zope2.custom_zodb']=m
+
 if hasattr(m,'DB'):
 DB=m.DB
+dbtab.databases.update(getattr(DB, 'databases', {}))
+DB.databases = dbtab.databases
 else:
-storage = m.Storage
-DB = ZODB.DB(storage)
+DB = ZODB.DB(m.Storage, databases=dbtab.databases)
 
-Globals.BobobaseName = DB.getName()
-sys.modules['Zope2.custom_zodb']=m
+Globals.BobobaseName = DB.getName()
 
 if DB.getActivityMonitor() is None:
 from ZODB.ActivityMonitor import ActivityMonitor

___
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins