Re: [Zope-dev] __getattr__ and Acquisition
Am Mit, 2002-09-25 um 10.06 schrieb Lennart Regebro: From: Andreas Kostyrka [EMAIL PROTECTED] And how do I return an attribute that is acquired (but not down th main acquisition path, but on a side line?) You shouldn't, really. Why not? I assume that I could probably play some silly games with __of__ to make my additional Acquisition objects to come just before my object in the acquisition path, ... Yup, much better idea. Done. Only thing I've noticed that the Catalog shows this additional path elements, ... See also www.zope.org/Members/yacc/FlexData ;), I've left the old __getattr__ hack commented in the source, ... Andreas -- Andreas Kostyrka [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
From: Andreas Kostyrka [EMAIL PROTECTED] To: Lennart Regebro [EMAIL PROTECTED] You shouldn't, really. Why not? Because that's not how it's supposed to work. You can override __getattr__ to have special magick attributes. Acquisition is not a special magick attribute. __getattr__ is only called when an attribute aren't found in a normal way, and in the context of Zope, Acquicistion would be regarded as normal. :-) Done. Only thing I've noticed that the Catalog shows this additional path elements, ... I guess that depends on when you patch in the extra object in the acquisition. If you do it in __of__() then I guess it's visible all the time. This may or may not be a good idea. :) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Am Mit, 2002-09-25 um 12.44 schrieb Lennart Regebro: From: Andreas Kostyrka [EMAIL PROTECTED] To: Lennart Regebro [EMAIL PROTECTED] You shouldn't, really. Why not? Because that's not how it's supposed to work. You can override __getattr__ to have special magick attributes. Acquisition is not a special magick attribute. __getattr__ is only called when an attribute aren't found in a normal way, and in the context of Zope, Acquicistion would be regarded as normal. :-) But my attributes are not normal. So I should generate them by __getattr__. Only by noticing that I could get the same effect by putting my attribute source in front of my object in the acquisition chain. The question is still, how does one a __getattr__ that needs (as a client) acquisition to calculate the attribute. (Basically __of__ works only if I do not need to know the attribute name and do not mind a changed acquisition chain, __getattr__ works only if I do not need Acquisition, ...) Done. Only thing I've noticed that the Catalog shows this additional path elements, ... I guess that depends on when you patch in the extra object in the acquisition. If you do it in __of__() then I guess it's visible all the Well, where else can I patch it in? Andreas -- Andreas Kostyrka [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Lennart Regebro writes: ... Because that's not how it's supposed to work. You can override __getattr__ to have special magick attributes. Acquisition is not a special magick attribute. __getattr__ is only called when an attribute aren't found in a normal way, and in the context of Zope, Acquicistion would be regarded as normal. :-) I had written the exact same statement some time ago. Nevertheless, it is wrong :( Now, I know it better: __getattr__ is used before acquisition comes into play. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
From: Andreas Kostyrka [EMAIL PROTECTED] But my attributes are not normal. So I should generate them by __getattr__. Only by noticing that I could get the same effect by putting my attribute source in front of my object in the acquisition chain. The question is still, how does one a __getattr__ that needs (as a client) acquisition to calculate the attribute. You don't. __getattr__ is used if you for example want data from a subobject to behave like it's attributes directly on the object. Trying to get data from another object in the ZODB to behave like they are attributes directly on the object with __gettattr__ is problematic, because that is not what it's designed for, and because in __getattr__ you don't have a context. Making data from another object in the ZODB to behave like they are attributes directly on the object is however exactly what Acquisition is designed for, and hence it's easier to do it that way. (Basically __of__ works only if I do not need to know the attribute name ??? Why wouldn't it work if you know the attribute name? What it doesn't do is to only work with some attributes, it works with all attributes, maybe that is what you mean? This usually don't give you any negative side effects. I guess that depends on when you patch in the extra object in the acquisition. If you do it in __of__() then I guess it's visible all the Well, where else can I patch it in? Overriding __of__ means that you are changing how the acquisition chain looks and behaves for the object. But you can also just wrap the object by calling __of__ whenever you need it wrapped instead of overriding it. If I remember the syntax correctly foo = self.__of__(magickfolder) would wrap self in magickfolder, and make it acquire magickfolders attributes, so that after doing this foo.bla would get the attribute from magickfolder if it doens't exist on self. This you can do just before you need that behaviour, and it will be a completely local behaviour. Don't spank me if I don't remember all the details here, I haven't looked at the code where we do this in a couple of months. :-) We insert our templates in the acquisition chain when index_html is called, so that the correct template is used when rendering. This insertion then only affects the rendering. From: Dieter Maurer [EMAIL PROTECTED] __getattr__ is used before acquisition comes into play. You are probably correct. Nevertheless, you can't push acquired object into the acqusition context in __getattr__, because the object inside __getattr__ has no context, and hence no objects are acquired. But of course it makes sense that __getattr__ is called before the acquisition comes into play, because otherwise you wouldn't be able to override acquired attributes. :-) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Andreas Kostyrka writes: I've just discovered, that Acquisition does not work with __getattr__, right? It does, just not the way, you expect it: The actual attribute lookup (for attributes not starting with aq_) is always made with an unwrapped object. That's the reason why the self in getattr is unwrapped. Special operations ensure for Python Methods (the one of ExtensionClass not Zope's!) that their self receives part of the acquisition context (it's rarely the full context, just enough to work in most cases). They are rebuild with the current node as self, when the recursive lookup comes back out of aq_self iff the method's self is aq_self. You may have a look at my Reference product http://www.dieter.handshake.de/pyprojects/zope There, I fight with the peculiarities of __getattr__ and acquisition context for methods. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 00.18 schrieb Lennart Regebro: From: Andreas Kostyrka [EMAIL PROTECTED] I've just discovered, that Acquisition does not work with __getattr__, right? That depends on what you mean with does not work. :-) (I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.) Anyway to get around that? (To basically get a wrapped self from somewhere?) That's what self usually is... :-) Nope it is not. In a normal method you can access something acquired like this: self.acquired_value. Even more, this works for __bobo_traverse__. It just works for the publishing not accessing my attributes later on during publication. The problem is, that __getattr__ does not have access to the acquisition chain. Now I storing the acquisition chain in the object is not a sound proposition, because it is not thread safe. Worse the object might be accessed in some way that makes the acquisition chain not be updated. I think you need to answer a couple of questions: 1. What is it you want to do? 2. How are you trying to do it? 3. What is happening when you try to do it? It's actually trivial ;) I want to acquire some things in __getattr__. Basically I want to insert an additional access step like this: 1.) a.b.c.o - o if o exists in c 2.) a.b.c.o - Folder.o (where Folder is acquired from a.b.c) if it's exist. 3.) a.b.c.o - tries to acquire o from a.b.c. Basically I want Transparent Folders which get their transparent values from the Acquisition path. Well, I just had an idea for an implementation: Third idea: I return some callable object the was generated specifically for the access from the __getattr__. This is than executed with Acquisition enabled, so it can try to get the real one, Problem: What if the attribute does not exist? I do not thing that Zope reacts to well when instead of a AttributeError exception it gets some object that raises AttributeError when accessed, Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
From: Andreas Kostyrka [EMAIL PROTECTED]
Nope it is not. In a normal method you can access something acquired
like this:
self.acquired_value.
I often do just that. :-) I'm not 100% sure what you need to include for
that to work, but I would expect that it is Aqcuisition.Implicit.
The problem is, that __getattr__ does not have access to the acquisition
chain.
Well, it does, but it typically causes infinite recursion if you aren't
careful. Something like this might work (this is untested code, adapted from
something that is a bit more complex that we are doing):
def __getattr__(self, name, marker=None):
if not name.startswith('_') and not name.startswith('aq_'):
if not name in self._v_ignore_attrib:
subob = getattr(self,name,_marker)
self._v_ignore_attrib=[]
# Return it in context of self, forgetting
# its location and acting as if it were located
# in self.
return aq_base(subob)
else:
self._v_ignore_attrib.append(name)
raise AttributeError, name
Basically I want Transparent Folders which get their transparent
values from the Acquisition path.
Aha. Well, I wouldn't call it trivial, but it is definitely doable.
Well, I just had an idea for an implementation:
Third idea: I return some callable object the was generated specifically
for the access from the __getattr__. This is than executed with
Acquisition enabled, so it can try to get the real one,
Problem: What if the attribute does not exist? I do not thing that Zope
reacts to well when instead of a AttributeError exception it gets some
object that raises AttributeError when accessed,
Andreas
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Andreas Kostyrka [EMAIL PROTECTED] wrote: Am Mon, 2002-09-23 um 00.18 schrieb Lennart Regebro: From: Andreas Kostyrka [EMAIL PROTECTED] I've just discovered, that Acquisition does not work with __getattr__, right? That depends on what you mean with does not work. :-) (I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.) Anyway to get around that? (To basically get a wrapped self from somewhere?) That's what self usually is... :-) Nope it is not. In a normal method you can access something acquired like this: self.acquired_value. Even more, this works for __bobo_traverse__. It just works for the publishing not accessing my attributes later on during publication. The problem is, that __getattr__ does not have access to the acquisition chain. Now I storing the acquisition chain in the object is not a sound proposition, because it is not thread safe. Worse the object might be accessed in some way that makes the acquisition chain not be updated. Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Andreas Kostyrka wrote: The problem is, that __getattr__ does not have access to the acquisition chain. I think it does, but I may be corrected. Some things to check for: 1. Do the classes of you object (and containing objects) inherit for Acquisition.Implicit? 2. Are you getting hold of the object in such a way that it is acquisition wrapped? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 10.35 schrieb Lennart Regebro:
From: Andreas Kostyrka [EMAIL PROTECTED]
Nope it is not. In a normal method you can access something acquired
like this:
self.acquired_value.
I often do just that. :-) I'm not 100% sure what you need to include for
that to work, but I would expect that it is Aqcuisition.Implicit.
Well, Acquisition does not work in __getattr__. This seems trivially
because the self is unwrapped in the case of __getattr__, while it's
wrapped when called on a normal method.
The problem is, that __getattr__ does not have access to the acquisition
chain.
Well, it does, but it typically causes infinite recursion if you aren't
Well, it would perhaps make sense for Acquisition to use the
equivalent of getattr(self.aq_explicit,name) instead of
getattr(aq_base(self),name)
This way you have no infinite recursion, but still can acquire things
explicitly with aq_acquire :)
careful. Something like this might work (this is untested code, adapted from
something that is a bit more complex that we are doing):
def __getattr__(self, name, marker=None):
if not name.startswith('_') and not name.startswith('aq_'):
if not name in self._v_ignore_attrib:
subob = getattr(self,name,_marker)
Well, where do you intenden your getattr to get the attribute from?
self._v_ignore_attrib=[]
# Return it in context of self, forgetting
# its location and acting as if it were located
# in self.
return aq_base(subob)
else:
self._v_ignore_attrib.append(name)
raise AttributeError, name
Basically I want Transparent Folders which get their transparent
values from the Acquisition path.
Aha. Well, I wouldn't call it trivial, but it is definitely doable.
Difficult. Because __getattr__ does not have access to the acquisition
chain. (Just looking at Acquisition.c makes my head go all jelly ;) )
1.) Change Acquisition to call getattr not on self but on an explicit
wrapper of self. see above.
Problem: Compability with Zope? Should probably work. But perhaps there
are things that rely on self being the object and not an explicit
Wrapper.
Problem: The idea of patching Acquisition.c makes my head spin.
Problem: Not possible to fix it up as an Product - needs a patch to
Zope.
2.) Fetch my a wrapped copy of self from the Python call stack.
Problem: It's an example of code that would be labelled Do not copy
this style!
Problem: Can break at the most curious moments.
3.) Store the wrapped self in some attribute during traversal.
Problem: This is plain wrong. It's not safe in a number of ways, ...
(threads, multiple acquisition paths, etc.)
I've implemented solution 2) because
- it's packable as a product
- I'm not sure a core change to Acquisition.c is something that has ANY
chance of getting into Zope.
- I'm not 100% sure that changing Acquisition.c will not break Zope in
some subtle ways.
- I'm already past the delivery deadline for my small application of
this. Hacking the Python stack seems something that I can predict much
better than any try to hack Acquisition.c :(
Andreas
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 13.10 schrieb Chris Withers: Andreas Kostyrka wrote: The problem is, that __getattr__ does not have access to the acquisition chain. I think it does, but I may be corrected. Well, it's definitly not wrapped. I know because I had to work around that. And it's definitly quite sick how I do this :) Some things to check for: 1. Do the classes of you object (and containing objects) inherit for Acquisition.Implicit? I inherit from OFS.Folder.Folder, this should be enough, wouldn't it? Especially Acquisition works quite well in all other methods, just not __getattr__. 2. Are you getting hold of the object in such a way that it is acquisition wrapped? Well, I'm not getting hold of anything. It's more like Zope is getting hold of my objects to publish. As I've solved my problem (well, it works, I understand the problem, and I know the correct solution, but I shying away of hacking Acquisition. It's easier (for me) to get my wrapper from the Python frame stack than to patch Acquisition.c.) Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume: Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :( Basically __getattr__ when called does not know it's containment anymore. :( Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
From: Andreas Kostyrka [EMAIL PROTECTED] Well, where do you intenden your getattr to get the attribute from? As I said, this is an example. This getattr part is supposed to be replaced with whatever you do to get the attribute. Otehrwise it would be rather useless, since it wouldn't do anything that isn't already done. :-) Difficult. Because __getattr__ does not have access to the acquisition chain. Well, you fix that with __of__, which is what I was going to say, but forgot. :-) I won't venture in giving you any example code, though, but the PortalSkins is one place to look. Also, depending of when you want the properties from the transparent folder to be aqcuirable you might be able to wrap the object by calling __of__ instead of overriding it. Best Regards Lennart Regebro, Torped http://www.easypublisher.com/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
At 16:29 2002-09-23 +, Florent Guillaume said: You didn't look a the code I pointed to you. Look at CMFCore/Skinnable to be precise (not everything is to be used of course). * In __of__ you store the parent in a volatile attribute, * in __getattr__ you lookup the volatile attribute This works as long as your object is not used in several different acquisition contexts. Hi Florent, Would you care to elaborate on that last sentence? :-) Could you give an example when it wouldn't work? Best Regards, Johan Carlsson -- Torped Strategi och Kommunikation AB Johan Carlsson [EMAIL PROTECTED] Mail: Birkagatan 9 SE-113 36 Stockholm Sweden Visit: Västmannagatan 67, Stockholm, Sweden Phone +46-(0)8-32 31 23 Fax +46-(0)8-32 31 83 Mobil +46-(0)70-558 25 24 http://www.torped.se http://www.easypublisher.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
Am Mon, 2002-09-23 um 18.29 schrieb Florent Guillaume: Andreas Kostyrka [EMAIL PROTECTED] wrote: Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume: Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :( Yes it does. __of__ is non-intuitive but it can work. So how do I call it? return myitem.__of__(self) Doesn't make sense, as self is not wrapped and as such DOES not contain any knowledge how it was accessed, ... /site1/shared/a/b/c/x /site2/shared/a/b/c/x might be quite different things? My problem especially is not generating a wrapper, but to acquire some object from up my acquisition chain, ... Basically __getattr__ when called does not know it's containment anymore. :( You didn't look a the code I pointed to you. Look at CMFCore/Skinnable to be precise (not everything is to be used of course). * In __of__ you store the parent in a volatile attribute, * in __getattr__ you lookup the volatile attribute This works as long as your object is not used in several different acquisition contexts. But exactly THIS I want to support. How should I know if the object will not be used sometime in the future with different contexts. How can I know that my content objects will not be recycled in a second Virtual Host? etc. Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
On Monday, September 23, 2002, at 09:14 AM, Andreas Kostyrka wrote: Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume: Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :( Basically __getattr__ when called does not know it's containment anymore. :( This is why my stock suggestion to needing to do anything with acquisition and __getattr__ (or any other acquisition jump-arounds) is: Don't. There are a lot of complexities that can arise out of Acquisition, Wrappers, and so on, that really require a deep understanding of exactly HOW acquisition works, versus what it usually does. The other problem with __getattr__ is interfacing with Persistence. ZODB handles it now, but it wasn't all that long ago that it couldn't. But with Acquisition - once you go beyond fair use, there's not enough Scotch in the world to kill the brain cramp. :) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] __getattr__ and Acquisition
Hi! I've just discovered, that Acquisition does not work with __getattr__, right? (I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.) Anyway to get around that? (To basically get a wrapped self from somewhere?) I see two solutions: -) I let some method (like pretraversal) acquire my object and store a reference in my object. This might work if the object is changed seldom and the method is called regularly enough, ... -) I walk the frame stack and extract the wrapped self from it. Not really nice, but then Zope does a number of black magic things :) Andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
From: Andreas Kostyrka [EMAIL PROTECTED] I've just discovered, that Acquisition does not work with __getattr__, right? That depends on what you mean with does not work. :-) (I assume that this is so because something like getattr(mybase,attr) is called during the acquisition process to prevent infinite recursion.) Anyway to get around that? (To basically get a wrapped self from somewhere?) That's what self usually is... :-) I think you need to answer a couple of questions: 1. What is it you want to do? 2. How are you trying to do it? 3. What is happening when you try to do it? It's hard to give solutions when you don't know the problem. :-) Best Regards Lennart Regebro http://www.easypublisher.com/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
