diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/narr/hybrid.rst | 46 |
1 files changed, 24 insertions, 22 deletions
diff --git a/docs/narr/hybrid.rst b/docs/narr/hybrid.rst index cb5f3abfc..2beb3aed9 100644 --- a/docs/narr/hybrid.rst +++ b/docs/narr/hybrid.rst @@ -124,7 +124,7 @@ The ``.views.foobar`` view callable above will be called when the URL Hybrid Applications ------------------- -Clearly *either* traversal or url dispatch can be used to create a +Clearly either traversal or url dispatch can be used to create a :mod:`repoze.bfg` application. However, it is possible to combine the competing concepts of traversal and url dispatch to resolve URLs to code within the same application. @@ -150,12 +150,13 @@ using route configuration that contains the special token When the this route is matched, :mod:`repoze.bfg` will attempt to use :term:`traversal` against the context implied by the :term:`root -factory` of this route. The above example isn't very useful unless -you've defined a custom :term:`root factory` by passing it to -constructor of a :class:`repoze.bfg.configuration.Configurator` -because the *default* root factory cannot be traversed (it has no -useful ``__getitem__`` method). But let's imagine that your root -factory looks like so: +factory` of this route. + +The above example isn't very useful unless you've defined a custom +:term:`root factory` by passing it to constructor of a +:class:`repoze.bfg.configuration.Configurator` because the *default* +root factory cannot be traversed (it has no useful ``__getitem__`` +method). But let's imagine that your root factory looks like so: .. code-block:: python @@ -173,28 +174,29 @@ factory looks like so: return root We've defined a bogus graph here that can be traversed, and a -``root_factory`` method that returns the root of the graph that we can -pass to our :class:`repoze.bfg.configuration.Configurator`. +``root_factory`` function that returns the root of the graph that we +can pass to our :class:`repoze.bfg.configuration.Configurator`. Because the ``Traversable`` object we've defined has a ``__getitem__`` method that does something nominally useful, using traversal against -the root implied by a route statement becomes a not-completely-insane -thing to do. +the root implied by a route statement becomes a reasonable thing to +do. Under the circumstance implied by ``:foo/:bar/*traverse``, traversal -is performed *after* the route matches. If the root factory returns a -traversable object, the "capture value" implied by the ``*traverse`` -element in the path pattern will be used to traverse the graph, -starting from the root object returned from the root factory. +is performed *after* the route matches. If the root factory +associated with that route returns a traversable object, the "capture +value" implied by the ``*traverse`` element in the path pattern will +be used to traverse the graph, starting from the root object returned +from the root factory. For example, if the URL requested by a user was -``http://example.com/one/two/a/b/c``, and the above route was matched -(some other route might match before this one does), the traversal -path used against the root would be ``a/b/c``. :mod:`repoze.bfg` will -attempt to traverse a graph through the edges ``a``, ``b``, and ``c``. -In our above example, that would imply that the *context* of the view -would be the ``Traversable`` object we've named ``c`` in our bogus -graph, using the ``.views.home`` view as the view callable. +``http://example.com/one/two/a/b/c``, and the above route was matched, +the traversal path used against the root would be ``a/b/c``. +:mod:`repoze.bfg` will attempt to traverse a graph through the edges +``a``, ``b``, and ``c``. In our above example, that would imply that +the *context* of the view would be the ``Traversable`` object we've +named ``c`` in our bogus graph, using the ``.views.home`` view as the +view callable. We can also define extra views that match a route: |