The route directive adds a single route configuration to the application registry.
The pattern of the route e.g. ideas/{idea}. This attribute is required. See route_pattern_syntax for information about the syntax of route patterns.
Note
For backwards compatibility purposes, the path attribute can also be used instead of pattern.
If you would like to cause the context to be something other than the root object when this route matches, you can spell a traversal pattern as the traverse argument. This traversal pattern will be used as the traversal path: traversal will begin at the root object implied by this route (either the global root, or the object returned by the factory associated with this route).
The syntax of the traverse argument is the same as it is for pattern. For example, if the pattern provided to the route directive is articles/{article}/edit, and the traverse argument provided to the route directive is /{article}, when a request comes in that causes the route to match in such a way that the article match value is ‘1’ (when the request URI is /articles/1/edit), the traversal path will be generated as /1. This means that the root object’s __getitem__ will be called with the name 1 during the traversal phase. If the 1 object exists, it will become the context of the request. traversal_chapter has more information about traversal.
If the traversal path contains segment marker names which are not present in the pattern argument, a runtime error will occur. The traverse pattern should not contain segment markers that do not exist in the pattern.
A similar combining of routing and traversal is available when a route is matched which contains a *traverse remainder marker in its pattern (see using_traverse_in_a_route_pattern). The traverse argument to the route directive allows you to associate route patterns with an arbitrary traversal path without using a a *traverse remainder marker; instead you can use other match information.
Note that the traverse argument to the route directive is ignored when attached to a route that has a *traverse remainder marker in its pattern.
custom_predicates
This value should be a sequence of references to custom predicate callables. Use custom predicates when no set of predefined predicates does what you need. Custom predicates can be combined with predefined predicates as necessary. Each custom predicate callable should accept two arguments: info and request and should return either True or False after doing arbitrary evaluation of the info and/or the request. If all custom and non-custom predicate callables return True the associated route will be considered viable for a given request. If any predicate callable returns False, route matching continues. Note that the value info passed to a custom route predicate is a dictionary containing matching information; see custom_route_predicates for more information about info.
The dotted Python name to a class or an interface that the context of the view should match for the view named by the route to be used. This attribute is only useful if the view attribute is used. If this attribute is not specified, the default (None) will be used.
If the view attribute is not provided, this attribute has no effect.
This attribute can also be spelled as view_for or for_; these are valid older spellings.
The permission name required to invoke the view associated with this route. e.g. edit. (see using_security_with_urldispatch for more information about permissions).
If the view attribute is not provided, this attribute has no effect.
This attribute can also be spelled as permission.
This is either a single string term (e.g. json) or a string implying a path or asset specification (e.g. templates/views.pt). If the renderer value is a single term (does not contain a dot .), the specified term will be used to look up a renderer implementation, and that renderer implementation will be used to construct a response from the view return value. If the renderer term contains a dot (.), the specified term will be treated as a path, and the filename extension of the last element in the path will be used to look up the renderer implementation, which will be passed the full path. The renderer implementation will be used to construct a response from the view return value. See views_which_use_a_renderer for more information.
If the view attribute is not provided, this attribute has no effect.
This attribute can also be spelled as renderer.
The view machinery defaults to using the __call__ method of the view callable (or the function itself, if the view callable is a function) to obtain a response dictionary. The attr value allows you to vary the method attribute used to obtain the response. For example, if your view was a class, and the class has a method named index and you wanted to use this method instead of the class’ __call__ method to return the response, you’d say attr="index" in the view configuration for the view. This is most useful when the view definition is a class.
If the view attribute is not provided, this attribute has no effect.
You can also add a route configuration via:
See also urldispatch_chapter.