traversal: different with and without a request
Hi, we stumbled over an annoyance that took a while to debug: Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test. In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not. We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent. Christian and Wolfgang -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Christian Theune wrote:
we stumbled over an annoyance that took a while to debug:
Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test.
In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not.
We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent.
zope.traversing is a mess. First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture. There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of "traversal" are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed. I'm not sure my explanation are helpful ;). Did I mention it was a mess?
On Wed, Oct 15, 2008 at 06:02:55PM +0200, Philipp von Weitershausen wrote:
Christian Theune wrote:
we stumbled over an annoyance that took a while to debug:
Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test.
In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not.
We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent.
zope.traversing is a mess.
You can drop the ".traversing" bit and it'll still be true. On the other hand Perl is a mess, yet it is quite successful.
First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture.
There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object.
I've seen these two called object traversal and URL traversal respectively.
zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of "traversal" are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed.
I'm not sure my explanation are helpful ;). Did I mention it was a mess?
Marius Gedminas -- Please do not even think about automatically normalizing file names anywhere. There is absolutely no need for introducing such nonsense, and deviating from the POSIX requirement that filenames be opaque byte strings is a Bad Idea[TM] (also known as NTFS). -- Markus Kuhn
Philipp von Weitershausen wrote:
First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture.
There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of "traversal" are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed.
I'm not sure my explanation are helpful ;). Did I mention it was a mess?
This is very useful information that would have saved me a lot of confusion years ago. Is this written somewhere permanent, at least? Everyone who does anything at all with ITraversable or IPublishTraverse needs to understand this, at least until traversal is redesigned. Shane
El 15 Oct 2008, a las 19:24 , Shane Hathaway escribió:
Philipp von Weitershausen wrote:
First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture.
There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of "traversal" are intermingled is when ++namespaces+ + are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed.
I'm not sure my explanation are helpful ;). Did I mention it was a mess?
This is very useful information that would have saved me a lot of confusion years ago. Is this written somewhere permanent, at least?
Not that I know of. The documentation of zope.traversing would probably be a good place to put it.
On Wed, 2008-10-15 at 18:02 +0200, Philipp von Weitershausen wrote:
Christian Theune wrote:
we stumbled over an annoyance that took a while to debug:
Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test.
In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not.
We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent.
zope.traversing is a mess.
First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below). The request shouldn't really be necessary for this kind of path resolution, I think. The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture.
There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of "traversal" are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed.
URL traversal makes use of zope.traversing though. -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
El 17 Oct 2008, a las 10:37 , Christian Theune escribió:
There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable). The only case when the two kinds of "traversal" are intermingled is when ++namespaces+ + are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed.
URL traversal makes use of zope.traversing though.
Yes, but only in the special case of ++namespace++ traversal. This is what I said in the above paragraph already. zope.publisher itself doesn't depend on zope.traversing and the default publication implementation in zope.app.publication uses zope.traversing only for + +namespace++ names (see usage of zope.traversing.namespace.nsParse in zope .app.publication.publicationtraverse.PublicationTraverse.traverseName).
On Oct 15, 2008, at 12:02 PM, Philipp von Weitershausen wrote:
Christian Theune wrote:
we stumbled over an annoyance that took a while to debug:
Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test.
In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not.
We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent.
zope.traversing is a mess.
That's a bit strong, but essentially true. It zope.traversing deserves to be reworked if anyone has the time and energy.
First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below).
Historical note. Until we decided to use the location framework and eschew traversal proxies, is was much more widely used. It would be nice to deprecate zope.traversing and fold it into zope.app.pagetemplate.
The request shouldn't really be necessary for this kind of path resolution, I think.
It's needed for looking up views and resources, both of which are commonly looked up in ZPT.
The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture.
<shrug /> I'll note that the fix, in the context of ZPT is to always to a multi- adapter lookup using the request.
There is a process that actually needs the request and this process is what I call traversal: breaking down a URL and finding a publishable object. zope.traversing has (almost) nothing to do with it, the real kind of traversal happens in the publisher and facilitates IPublishTraverse adapters (rather than ITraversable).
Yup.
The only case when the two kinds of "traversal" are intermingled is when ++namespaces++ are involved. Then IPublishTraverse-style traversal uses ITraversable adapters. This has long been considered a mistake but was never fixed.
Yup. I would go so far as to call it a bug. Somebody please fix it. :) Jim -- Jim Fulton Zope Corporation
El 17 Oct 2008, a las 15:02 , Jim Fulton escribió:
First of all, its name is quite misleading. It should really be called 'zope.resolvepath' because it resolves TALES-like object paths. In fact, it's pretty much only used by the PageTemplate machinery to hook it up to the TALES engine (with one exception, see below).
Historical note. Until we decided to use the location framework and eschew traversal proxies, is was much more widely used.
It would be nice to deprecate zope.traversing and fold it into zope.app.pagetemplate.
+1
The request shouldn't really be necessary for this kind of path resolution, I think.
It's needed for looking up views and resources, both of which are commonly looked up in ZPT.
Yeah, I forgot about that.
The conditional multi-adaption sounds like a DWIM feature that I would consider one of our many mistakes that we made in the beginnings of our using the Component Architecture.
<shrug />
I'll note that the fix, in the context of ZPT is to always to a multi-adapter lookup using the request.
Right. I'm fine with it always being a multi-adapter look-up.
On Friday 17 October 2008, Jim Fulton wrote:
It would be nice to deprecate zope.traversing and fold it into zope.app.pagetemplate.
Just skimming the thread, wouldn't this make it harder for us to integrate z3c.pt, which also needs those traversal APIs? Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Oct 17, 2008, at 1:13 PM, Stephan Richter wrote:
On Friday 17 October 2008, Jim Fulton wrote:
It would be nice to deprecate zope.traversing and fold it into zope.app.pagetemplate.
Just skimming the thread, wouldn't this make it harder for us to integrate z3c.pt, which also needs those traversal APIs?
Yup. Actually, this wants to be in zope.tales. Does z3c.pt use zope.tales? Jim -- Jim Fulton Zope Corporation
Previously Jim Fulton wrote:
On Oct 17, 2008, at 1:13 PM, Stephan Richter wrote:
On Friday 17 October 2008, Jim Fulton wrote:
It would be nice to deprecate zope.traversing and fold it into zope.app.pagetemplate.
Just skimming the thread, wouldn't this make it harder for us to integrate z3c.pt, which also needs those traversal APIs?
Yup. Actually, this wants to be in zope.tales. Does z3c.pt use zope.tales?
No. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Christian Theune wrote at 2008-10-15 17:42 +0200:
we stumbled over an annoyance that took a while to debug:
Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test.
In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not.
We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent.
The request may have important information to control traversal, e.g. a layer. On the other hand, when no request is available (e.g. in a script), you cannot use one. Thus, the current behaviour may cover useful use cases. Maybe, you should not trust your tests stupidly -- unless they emulate the actual system sufficently ;-) -- Dieter
Dieter Maurer wrote:
Christian Theune wrote at 2008-10-15 17:42 +0200:
we stumbled over an annoyance that took a while to debug:
Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test.
In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not.
We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent.
The request may have important information to control traversal, e.g. a layer. On the other hand, when no request is available (e.g. in a script), you cannot use one. Thus, the current behaviour may cover useful use cases.
True. The request (=layer) is indeed necessary to resolve paths in the ++view++ aka @@ namespace.
On Wed, 2008-10-15 at 20:34 +0200, Dieter Maurer wrote:
Christian Theune wrote at 2008-10-15 17:42 +0200:
we stumbled over an annoyance that took a while to debug:
Writing an ITraversable, we used zope.traversing.api.traverse() in a test to verify our code. We registered the ITraversable as an (non-multi) adapter and ended up with a working test.
In the actual system, we found that the traversable would not be used. After investigation we found a conditional branch in the traverse() function which would look for a multi-adapter if a request was around, and a regular adapter if not.
We didn't anticipate this difference and it cost us some time, so we wonder whether this has to be the way it is, or whether this could be changed to behave more obvious and consistent.
The request may have important information to control traversal, e.g. a layer. On the other hand, when no request is available (e.g. in a script), you cannot use one. Thus, the current behaviour may cover useful use cases.
I'm not arguing that the behaviour wouldn't be useful in some cases, I'm just arguing it's not obvious. Philipp's pointer to the whole area being messy is correct. This might be a good sprint topic.
Maybe, you should not trust your tests stupidly -- unless they emulate the actual system sufficently ;-)
I only found this because I'm not trusting my tests blindly and I both tested automatically and manually to verify that the test actually does test what I want. ;) Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (8)
-
Christian Theune -
Dieter Maurer -
Jim Fulton -
Marius Gedminas -
Philipp von Weitershausen -
Shane Hathaway -
Stephan Richter -
Wichert Akkerman