8. URL DISPATCH

8.4 Routing Examples

Let’s check out some examples of how route configuration statements might be commonly declared, and what will happen if they are matched by the information present in a request.

8.4.1 Example 1

The simplest route declaration which configures a route match to directly result in a particular view callable being invoked:

1config.add_route(’idea’, ’site/{id}’)

2config.add_view(’mypackage.views.site_view’, route_name=’idea’)

When a route configuration with a view attribute is added to the system, and an incoming request matches the pattern of the route configuration, the view callable named as the view attribute of the route configuration will be invoked.

In the case of the above example, when the URL of a request matches /site/{id}, the view callable at the Python dotted path name mypackage.views.site_view will be called with the request. In other words, we’ve associated a view callable directly with a route pattern.

When the /site/{id} route pattern matches during a request, the site_view view callable is invoked with that request as its sole argument. When this route matches, a matchdict will be generated and attached to the request as request.matchdict. If the specific URL matched is /site/1, the matchdict will be a dictionary with a single key, id; the value will be the string ’1’, ex.:

{’id’:’1’}.

The mypackage.views module referred to above might look like so:

1

2

3

4

from pyramid.response import Response

def site_view(request):

return Response(request.matchdict[’id’])

The view has access to the matchdict directly via the request, and can access variables within it that match keys present as a result of the route pattern.

See Views, and View Configuration for more information about views.

8.4.2 Example 2

Below is an example of a more complicated set of route statements you might add to your application:

80

8.4. ROUTING EXAMPLES

1 config.add_route(’idea’, ’ideas/{idea}’) 2 config.add_route(’user’, ’users/{user}’) 3 config.add_route(’tag’, ’tags/{tags}’)

4

5 config.add_view(’mypackage.views.idea_view’, route_name=’idea’) 6 config.add_view(’mypackage.views.user_view’, route_name=’user’) 7 config.add_view(’mypackage.views.tag_view’, route_name=’tag’)

The above configuration will allow Pyramid to service URLs in these forms:

/ideas/{idea}

/users/{user}

/tags/{tag}

•When a URL matches the pattern /ideas/{idea}, the view callable available at the dotted Python pathname mypackage.views.idea_view will be called. For the specific URL /ideas/1, the matchdict generated and attached to the request will consist of

{’idea’:’1’}.

•When a URL matches the pattern /users/{user}, the view callable available at the dotted Python pathname mypackage.views.user_view will be called. For the specific URL /users/1, the matchdict generated and attached to the request will consist of

{’user’:’1’}.

•When a URL matches the pattern /tags/{tag}, the view callable available at the dotted Python pathname mypackage.views.tag_view will be called. For the specific URL /tags/1, the matchdict generated and attached to the request will consist of {’tag’:’1’}.

In this example we’ve again associated each of our routes with a view callable directly. In all cases, the request, which will have a matchdict attribute detailing the information found in the URL by the process will be passed to the view callable.

8.4.3 Example 3

The context resource object passed in to a view found as the result of URL dispatch will, by default, be an instance of the object returned by the root factory configured at startup time (the root_factory argument to the Configurator used to configure the application).

You can override this behavior by passing in a factory argument to the add_route() method for a particular route. The factory should be a callable that accepts a request and returns an instance of a class that will be the context resource used by the view.

An example of using a route with a factory:

81