28.3. CORNER CASES

1

2

config.add_route(’abc’, ’/abc/*traverse’, use_global_views=True) config.add_view(’myproject.views.bazbuz’, name=’bazbuz’)

28.2.4 Using *subpath in a Route Pattern

There are certain extremely rare cases when you’d like to influence the traversal subpath when a route matches without actually performing traversal. For instance, the pyramid.wsgi.wsgiapp2() decorator and the pyramid.static.static_view helper attempt to compute PATH_INFO from the request’s subpath when its use_subpath argument is True, so it’s useful to be able to influence this value.

When *subpath exists in a pattern, no path is actually traversed, but the traversal algorithm will return a subpath list implied by the capture value of *subpath. You’ll see this pattern most commonly in route declarations that look like this:

1 from pryamid.static import static_view

2

3 www = static_view(’mypackage:static’, use_subpath=True)

4

5 config.add_route(’static’, ’/static/*subpath’) 6 config.add_view(www, route_name=’static’)

mypackage.views.www is an instance of pyramid.static.static_view. This effectively tells the static helper to traverse everything in the subpath as a filename.

28.3 Corner Cases

A number of corner case “gotchas” exist when using a hybrid application. We’ll detail them here.

28.3.1 Registering a Default View for a Route That Has a view Attribute

latex-warning.png

As of Pyramid 1.1 this section is slated to be removed in a later documentation release because the the ability to add views directly to the route configuration by passing a view argument to add_route has been deprecated.

313

28. COMBINING TRAVERSAL AND URL DISPATCH

It is an error to provide both a view argument to a route configuration and a view configuration which names a route_name that has no name value or the empty name value. For example, this pair of declarations will generate a conflict error at startup time.

1

2

3

config.add_route(’home’, ’{foo}/{bar}/*traverse’, view=’myproject.views.home’)

config.add_view(’myproject.views.another’, route_name=’home’)

This is because the view argument to the add_route() above is an implicit default view when that route matches. add_route calls don’t need to supply a view attribute. For example, this add_route call:

1

2

config.add_route(’home’, ’{foo}/{bar}/*traverse’, view=’myproject.views.home’)

Can also be spelled like so:

1

2

config.add_route(’home’, ’{foo}/{bar}/*traverse’) config.add_view(’myproject.views.home’, route_name=’home’)

The two spellings are logically equivalent. In fact, the former is just a syntactical shortcut for the latter.

28.3.2Binding Extra Views Against a Route Configuration that Doesn’t Have a *traverse Element In Its Pattern

Here’s another corner case that just makes no sense:

1

2

3

config.add_route(’abc’, ’/abc’, view=’myproject.views.abc’) config.add_view(’myproject.views.bazbuz’, name=’bazbuz’,

route_name=’abc’)

The above view declaration is useless, because it will never be matched when the route it references has matched. Only the view associated with the route itself (myproject.views.abc) will ever be invoked when the route matches, because the default view is always invoked when a route matches and when no post-match traversal is performed.

To make the above view declaration useful, the special *traverse token must end the route’s pattern. For example:

314

28.3. CORNER CASES

1

2

3

config.add_route(’abc’, ’/abc/*traverse’, view=’myproject.views.abc’) config.add_view(’myproject.views.bazbuz’, name=’bazbuz’,

route_name=’abc’)

With the above configuration, the myproject.views.bazbuz view will be invoked when the request URI is /abc/bazbuz, assuming there is no object contained by the root object with the key bazbuz. A different request URI, such as /abc/foo/bar, would invoke the default myproject.views.abc view.

315

28. COMBINING TRAVERSAL AND URL DISPATCH

316