New submission from Will Seaver <will.sea...@gmail.com>:
My big question for this chapter is: Isn't the way that URL dispatch works much
like a hybrid application to begin with? If a route cannot be found to match a
request, traversal is undertaken, therefore performing all of the functions of a
hybrid application. I can derive that the usefulness comes from the ability have
multiple root objects, which is useful for setting up an authentication policy
(I think? I could be completely turned around), but beyond that I don't see the
p. 97: "A *traverse token at the end of the path in a route's configuration
implies a "stararg" capture value. When it is used, it will match the remainder
of the path segments of the URL. This remainder becomes the path used to perform
traversal." So if the route is "/foo/bar/*traverse", and the path_info given is
"/foo/bar/1/2/3/" then the path used to perform traversal is "/1/2/3/"?
root factory (p. 97: ...repoze.bfg will attempt to use traversal against the
root object implied by the root factory.")
in the example given on p. 97:
root = Traversable(
This is clearly the crux of the Traversable class, the thing that sets
everything into motion, and I can't make heads or tails of it. Explanation?
p. 98: "If the URL that matched a route with the path :foo/:bar/*traverse, is
http://example.com/one/two/a/b/c, the traversal path used against the root
object will be a/b/c. As a result, repoze.bfg will attempt to traverse through
the edges a, b, and c, beginning at the root object." What is the root object in
the given example?
Also, the question of the __getitem__ method comes back to haunt me in this
chapter. If I knew how to determine which objects possessed the __getitem__
method, I would be much more equipped to puzzle out the finer points of
section 9.3.2: Binding Extra Views Against a Route Configuration that Doesn't
Have a *traverse Element in Its Path
I need a hand with this one.
title: chapter 9
topic: bfg book
Repoze Bugs <b...@bugs.repoze.org>
Repoze-dev mailing list