From 74409d12f7eb085bc992a200cc74799e4d1ff355 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Wed, 8 Sep 2010 04:25:35 +0000 Subject: - The ``repoze.bfg.urldispatch.Route`` constructor (not an API) now accepts a different ordering of arguments. Previously it was ``(pattern, name, factory=None, predicates=())``. It is now ``(name, pattern, factory=None, predicates=())``. This is in support of consistency with ``configurator.add_route``. - The ``repoze.bfg.urldispatch.RoutesMapper.connect`` method (not an API) now accepts a different ordering of arguments. Previously it was ``(pattern, name, factory=None, predicates=())``. It is now ``(name, pattern, factory=None, predicates=())``. This is in support of consistency with ``configurator.add_route``. - The ``repoze.bfg.urldispatch.RoutesMapper`` object now has a ``get_route`` method which returns a single Route object or ``None``. - A new interface ``repoze.bfg.interfaces.IRoute`` was added. The ``repoze.bfg.urldispatch.Route`` object implements this interface. - The canonical attribute for accessing the routing pattern from a route object is now ``pattern`` rather than ``path``. - The argument to ``repoze.bfg.configuration.Configurator.add_route`` which was previously called ``path`` is now called ``pattern`` for better explicability. For backwards compatibility purposes, passing a keyword argument named ``path`` to ``add_route`` will still work indefinitely. - The ``path`` attribute to the ZCML ``route`` directive is now named ``pattern`` for better explicability. The older ``path`` attribute will continue to work indefinitely. - All narrative, API, and tutorial docs which referred to a route pattern as a ``path`` have now been updated to refer to them as a ``pattern``. - The routesalchemy template has been updated to use ``pattern`` in its route declarations rather than ``path``. --- docs/narr/hybrid.rst | 96 ++++++------- docs/narr/router.rst | 6 +- docs/narr/urldispatch.rst | 159 +++++++++++---------- docs/narr/views.rst | 2 +- docs/tutorials/bfgwiki2/basiclayout.rst | 2 +- docs/tutorials/bfgwiki2/definingviews.rst | 21 +-- .../src/authorization/tutorial/configure.zcml | 14 +- .../src/basiclayout/tutorial/configure.zcml | 5 +- .../bfgwiki2/src/models/tutorial/configure.zcml | 5 +- .../bfgwiki2/src/views/tutorial/configure.zcml | 10 +- docs/zcml/route.rst | 43 +++--- 11 files changed, 187 insertions(+), 176 deletions(-) (limited to 'docs') diff --git a/docs/narr/hybrid.rst b/docs/narr/hybrid.rst index be2689c68..021162d0b 100644 --- a/docs/narr/hybrid.rst +++ b/docs/narr/hybrid.rst @@ -40,13 +40,13 @@ to code will often have declarations like this within :term:`ZCML`: :linenos: @@ -105,9 +105,9 @@ application than it is like a "pure" URL-dispatch based application. But unlike in a "pure" traversal-based application, in a hybrid application, :term:`traversal` is performed during a request after a route has already matched. This means that the URL pattern that -represents the ``path`` argument of a route must match the -``PATH_INFO`` of a request, and after the route path has matched, most -of the "normal" rules of traversal with respect to :term:`context +represents the ``pattern`` argument of a route must match the +``PATH_INFO`` of a request, and after the route pattern has matched, +most of the "normal" rules of traversal with respect to :term:`context finding` and :term:`view lookup` apply. There are only four real differences between a purely traversal-based @@ -125,7 +125,7 @@ application and a hybrid application: underlying :term:`WSGI` environment is used wholesale as a traversal path; in a hybrid application, the traversal path is not the entire ``PATH_INFO`` string, but a portion of the URL determined by a - matching pattern in the matched route configuration's path. + matching pattern in the matched route configuration's pattern. - In a purely traversal based application, view configurations which do not mention a ``route_name`` argument are considered during @@ -151,7 +151,7 @@ application except: To create a hybrid mode application, use a :term:`route configuration` that implies a particular :term:`root factory` and which also includes -a ``path`` argument that contains a special dynamic part: either +a ``pattern`` argument that contains a special dynamic part: either ``*traverse`` or ``*subpath``. The Root Object for a Route Match @@ -188,32 +188,32 @@ match is straightforward. When a route is matched: root factory were explained previously within :ref:`the_object_graph`. -.. _using_traverse_in_a_route_path: +.. _using_traverse_in_a_route_pattern: -Using ``*traverse`` In a Route Path -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Using ``*traverse`` In a Route Pattern +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A hybrid application most often implies the inclusion of a route configuration that contains the special token ``*traverse`` at the end -of a route's path: +of a route's pattern: .. code-block:: xml :linenos: -A ``*traverse`` token at the end of the path in a route's +A ``*traverse`` token at the end of the pattern in a route's configuration implies a "remainder" *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. .. note:: - The ``*remainder`` route path pattern syntax is explained in more - detail within :ref:`route_path_pattern_syntax`. + The ``*remainder`` route pattern syntax is explained in more + detail within :ref:`route_pattern_syntax`. Note that unlike the examples provided within :ref:`urldispatch_chapter`, the ```` configuration named @@ -223,7 +223,7 @@ hybrid mode application relies on :term:`traversal` to do invoking a specific view callable named directly within the matched route's configuration. -Because the path of the above route ends with ``*traverse``, when this +Because the pattern of the above route ends with ``*traverse``, when this route configuration is matched during a request, :mod:`repoze.bfg` will attempt to use :term:`traversal` against the :term:`root` object implied by the :term:`root factory` implied by the route's @@ -263,7 +263,7 @@ route configuration statement: :linenos: @@ -288,15 +288,15 @@ to do. global ``root_factory`` function to generate a root object. When the route configuration named ``home`` above is matched during a -request, the matchdict generated will be based on its path: +request, the matchdict generated will be based on its pattern: ``:foo/:bar/*traverse``. The "capture value" implied by the -``*traverse`` element in the path pattern will be used to traverse the +``*traverse`` element in the pattern will be used to traverse the graph in order to find a context, starting from the root object returned from the root factory. In the above example, the :term:`root` object found will be the instance named ``root`` in ``routes.py``. -If the URL that matched a route with the path ``:foo/:bar/*traverse``, +If the URL that matched a route with the pattern ``: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, :mod:`repoze.bfg` will attempt to traverse through the edges ``a``, @@ -319,7 +319,7 @@ invoked after a route matches: :linenos: @@ -355,7 +355,7 @@ when a hybrid route is matched: :linenos: @@ -395,8 +395,8 @@ arguments). Using the ``traverse`` Argument In a Route Definition ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Rather than using the ``*traverse`` remainder marker in a path -pattern, you can use the ``traverse`` argument to the +Rather than using the ``*traverse`` remainder marker in a pattern, you +can use the ``traverse`` argument to the :meth:`repoze.bfg.configuration.Configurator.add_route`` method or the ``traverse`` attribute of the :ref:`route_directive` ZCML directive. (either method is equivalent). @@ -414,16 +414,16 @@ declaration: The syntax of the ``traverse`` argument is the same as it is for -``path``. +``pattern``. -If, as above, the ``path`` provided is ``articles/:article/edit``, and -the ``traverse`` argument provided is ``/:article``, when a request -comes in that causes the route to match in such a way that the +If, as above, the ``pattern`` provided is ``articles/:article/edit``, +and the ``traverse`` argument provided 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 @@ -432,12 +432,12 @@ exists, it will become the :term:`context` of the request. :ref:`traversal_chapter` has more information about traversal. If the traversal path contains segment marker names which are not -present in the path argument, a runtime error will occur. The +present in the pattern argument, a runtime error will occur. The ``traverse`` pattern should not contain segment markers that do not exist in the ``path``. Note that the ``traverse`` argument is ignored when attached to a -route that has a ``*traverse`` remainder marker in its path. +route that has a ``*traverse`` remainder marker in its pattern. Traversal will begin at the root object implied by this route (either the global root, or the object returned by the ``factory`` associated @@ -448,7 +448,7 @@ Making Global Views Match By default, view configurations that don't mention a ``route_name`` will be not found by view lookup when a route that mentions a -``*traverse`` in its path matches. You can make these match forcibly +``*traverse`` in its pattern matches. You can make these match forcibly by adding the ``use_global_views`` flag to the route definition. For example, the ``views.bazbuz`` view below will be found if the route named ``abc`` below is matched and the ``PATH_INFO`` is @@ -459,7 +459,7 @@ have the ``route_name="abc"`` attribute. :linenos: @@ -475,8 +475,8 @@ have the ``route_name="abc"`` attribute. .. _star_subpath: -Using ``*subpath`` in a Route Path -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Using ``*subpath`` in a Route Pattern +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are certain extremely rare cases when you'd like to influence the traversal :term:`subpath` when a route matches without actually @@ -486,16 +486,16 @@ performing traversal. For instance, the ``PATH_INFO`` from the request's subpath, so it's useful to be able to influence this value. -When ``*subpath`` exists in a path pattern, no path is actually -traversed, but the traversal algorithm will return a :term:`subpath` -list implied by the capture value of ``*subpath``. You'll see this -pattern most commonly in route declarations that look like this: +When ``*subpath`` exists in a pattern, no path is actually traversed, +but the traversal algorithm will return a :term:`subpath` list implied +by the capture value of ``*subpath``. You'll see this pattern most +commonly in route declarations that look like this: .. code-block:: xml :linenos: @@ -523,7 +523,7 @@ For example, this pair of route/view ZCML declarations will generate a :linenos: @@ -542,7 +542,7 @@ example, this ```` statement: :linenos: @@ -553,7 +553,7 @@ Can also be spelled like so: :linenos: @@ -565,8 +565,8 @@ Can also be spelled like so: The two spellings are logically equivalent. In fact, the former is just a syntactical shortcut for the latter. -Binding Extra Views Against a Route Configuration that Doesn't Have a ``*traverse`` Element In Its Path -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Binding Extra Views Against a Route Configuration that Doesn't Have a ``*traverse`` Element In Its Patttern +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here's another corner case that just makes no sense. @@ -574,7 +574,7 @@ Here's another corner case that just makes no sense. :linenos: @@ -592,13 +592,13 @@ 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 ```` declaration non-useless, the special -``*traverse`` token must end the route's path. For example: +``*traverse`` token must end the route's pattern. For example: .. code-block:: xml :linenos: diff --git a/docs/narr/router.rst b/docs/narr/router.rst index 8c6407a72..025d70157 100644 --- a/docs/narr/router.rst +++ b/docs/narr/router.rst @@ -33,9 +33,9 @@ processing? configuration, the :mod:`repoze.bfg` :term:`router` calls a :term:`URL dispatch` "route mapper." The job of the mapper is to examine the ``PATH_INFO`` implied by the request to determine - whether any user-defined :term:`route` matches the current WSGI - environment. The :term:`router` passes the request as an argument - to the mapper. + whether any user-defined :term:`route` pattern matches the current + WSGI environment. The :term:`router` passes the request as an + argument to the mapper. #. If any route matches, the WSGI environment is mutated; a ``bfg.routes.route`` key and a ``bfg.routes.matchdict`` are added diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst index 7c8bb7ce6..6a5a24c81 100644 --- a/docs/narr/urldispatch.rst +++ b/docs/narr/urldispatch.rst @@ -65,12 +65,12 @@ Route Configuration ------------------- :term:`Route configuration` is the act of adding a new :term:`route` -to an application. A route has a *path*, representing a pattern meant -to match against the ``PATH_INFO`` portion of a URL, and a *name*, -which is used by developers within a :mod:`repoze.bfg` application to -uniquely identify a particular route when generating a URL. It also -optionally has a ``factory``, a set of :term:`route predicate` -parameters, and a set of :term:`view` parameters. +to an application. A route has a *pattern*, representing a pattern +meant to match against the ``PATH_INFO`` portion of a URL, and a +*name*, which is used by developers within a :mod:`repoze.bfg` +application to uniquely identify a particular route when generating a +URL. It also optionally has a ``factory``, a set of :term:`route +predicate` parameters, and a set of :term:`view` parameters. A route configuration may be added to the system via :term:`imperative configuration` or via :term:`ZCML`. Both are completely equivalent. @@ -92,7 +92,7 @@ registry`. Here's an example: # repoze.bfg.configuration.Configurator class; "myview" is assumed # to be a "view callable" function from views import myview - config.add_route(name='myroute', path='/prefix/:one/:two', view=myview) + config.add_route('myroute', '/prefix/:one/:two', view=myview) .. index:: single: ZCML directive; route @@ -111,7 +111,7 @@ application. @@ -149,22 +149,21 @@ Here's an example route configuration that references a view callable: When a route configuration names a ``view`` attribute, the :term:`view callable` named as that ``view`` attribute will always be found and -invoked when the associated route path pattern matches during a -request. +invoked when the associated route pattern matches during a request. The purpose of making it possible to specify a view callable within a route configuration is to prevent developers from needing to deeply understand the details of :term:`context finding` and :term:`view lookup`. When a route names a view callable, and a request enters the -system which matches the path of the route, the result is simple: the -view callable associated with the route is invoked with the request -that caused the invocation. +system which matches the pattern of the route, the result is simple: +the view callable associated with the route is invoked with the +request that caused the invocation. For most usage, you needn't understand more than this; how it works is an implementation detail. In the interest of completeness, however, @@ -176,8 +175,8 @@ Route View Callable Registration and Lookup Details When a ``view`` attribute is attached to a route configuration, :mod:`repoze.bfg` ensures that a :term:`view configuration` is -registered that will always be found when the route path pattern is -matched during a request. To do so: +registered that will always be found when the route pattern is matched +during a request. To do so: - A special route-specific :term:`interface` is created at startup time for each route configuration declaration. @@ -194,7 +193,7 @@ matched during a request. To do so: - The fact that the request is decorated with a route-specific interface causes the view lookup machinery to always use the view callable registered using that interface by the route configuration - to service requests that match the route path pattern. + to service requests that match the route pattern. In this way, we supply a shortcut to the developer. Under the hood, :mod:`repoze.bfg` still consumes the :term:`context finding` and @@ -207,19 +206,19 @@ various exceptional cases as documented in :ref:`hybrid_chapter`. .. index:: single: route path pattern syntax -.. _route_path_pattern_syntax: +.. _route_pattern_syntax: -Route Path Pattern Syntax -~~~~~~~~~~~~~~~~~~~~~~~~~ +Route Pattern Syntax +~~~~~~~~~~~~~~~~~~~~ The syntax of the pattern matching language used by :mod:`repoze.bfg` -URL dispatch in the *path* argument is straightforward; it is close to -that of the :term:`Routes` system used by :term:`Pylons`. +URL dispatch in the *pattern* argument is straightforward; it is close +to that of the :term:`Routes` system used by :term:`Pylons`. -The *path* used in route configuration may start with a slash -character. If the path does not start with a slash character, an +The *pattern* used in route configuration may start with a slash +character. If the pattern does not start with a slash character, an implicit slash will be prepended to it at matching time. For example, -the following paths are equivalent: +the following patterns are equivalent: .. code-block:: text @@ -231,10 +230,10 @@ and: /:foo/bar/baz -A path segment (an individual item between ``/`` characters in the -path) may either be a literal string (e.g. ``foo``) *or* it may be a -segment replacement marker (e.g. ``:foo``) or a certain combination of -both. +A patttern segment (an individual item between ``/`` characters in the +pattern) may either be a literal string (e.g. ``foo``) *or* it may be +a segment replacement marker (e.g. ``:foo``) or a certain combination +of both. A segment replacement marker is in the format ``:name``, where this means "accept any characters up to the next nonalphaunumeric character @@ -314,8 +313,8 @@ decoded): If the pattern has a ``*`` in it, the name which follows it is considered a "remainder match". A remainder match *must* come at the -end of the path pattern. Unlike segment replacement markers, it does -not need to be preceded by a slash. For example: +end of the pattern. Unlike segment replacement markers, it does not +need to be preceded by a slash. For example: .. code-block:: text @@ -405,7 +404,7 @@ found via :term:`view lookup`. .. code-block:: xml When a route configuration with a ``view`` attribute is added to the -system, and an incoming request matches the *path* of the route +system, and an incoming request matches the *pattern* of the route configuration, the :term:`view callable` named as the ``view`` attribute of the route configuration will be invoked. @@ -835,15 +838,15 @@ 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 -path. +pattern. -When the ``/site/:id`` route path 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'}``. +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: @@ -857,7 +860,7 @@ The ``mypackage.views`` module referred to above might look like so: 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 path pattern. +route pattern. See :ref:`views_chapter` for more information about views. @@ -872,19 +875,19 @@ might add to your application: @@ -941,7 +944,7 @@ An example of using a route with a factory: @@ -972,7 +975,7 @@ a ``view`` declaration. @@ -1007,26 +1010,26 @@ in :ref:`hybrid_chapter`. Matching the Root URL --------------------- -It's not entirely obvious how to use a route path pattern to match the -root URL ("/"). To do so, give the empty string as a path in a ZCML +It's not entirely obvious how to use a route pattern to match the root +URL ("/"). To do so, give the empty string as a pattern in a ZCML ``route`` declaration: .. code-block:: xml :linenos: -Or provide the literal string ``/`` as the path: +Or provide the literal string ``/`` as the pattern: .. code-block:: xml :linenos: @@ -1039,9 +1042,9 @@ Generating Route URLs --------------------- Use the :func:`repoze.bfg.url.route_url` function to generate URLs -based on route paths. For example, if you've configured a route in -ZCML with the ``name`` "foo" and the ``path`` ":a/:b/:c", you might do -this. +based on route patterns. For example, if you've configured a route in +ZCML with the ``name`` "foo" and the ``pattern`` ":a/:b/:c", you might +do this. .. ignore-next-block .. code-block:: python @@ -1070,8 +1073,8 @@ For behavior like Django's ``APPEND_SLASH=True``, use the Found view (indicating that no view was found), and any routes have been defined in the configuration of your application, if the value of ``PATH_INFO`` does not already end in a slash, and if the value of -``PATH_INFO`` *plus* a slash matches any route's path, it does an HTTP -redirect to the slash-appended ``PATH_INFO``. +``PATH_INFO`` *plus* a slash matches any route's pattern, it does an +HTTP redirect to the slash-appended ``PATH_INFO``. Let's use an example, because this behavior is a bit magical. If the ``append_slash_notfound_view`` is configured in your application and @@ -1082,12 +1085,12 @@ your route configuration looks like so: If a request enters the application with the ``PATH_INFO`` value of diff --git a/docs/narr/views.rst b/docs/narr/views.rst index 4d60f8a9e..5b55e7e12 100644 --- a/docs/narr/views.rst +++ b/docs/narr/views.rst @@ -1240,7 +1240,7 @@ Predicate Arguments declaration (see :ref:`urldispatch_chapter`) that must match before this view will be called. Note that the ``route`` configuration referred to by ``route_name`` usually has a ``*traverse`` token in - the value of its ``path``, representing a part of the path that will + the value of its ``pattern``, representing a part of the path that will be used by :term:`traversal` against the result of the route's :term:`root factory`. diff --git a/docs/tutorials/bfgwiki2/basiclayout.rst b/docs/tutorials/bfgwiki2/basiclayout.rst index a284b2eb4..e09316fab 100644 --- a/docs/tutorials/bfgwiki2/basiclayout.rst +++ b/docs/tutorials/bfgwiki2/basiclayout.rst @@ -35,7 +35,7 @@ following: #. *Lines 6-11*. Register a ```` :term:`route configuration` that will be used when the URL is ``/``. Since this ```` - has an empty ``path`` attribute, it is the "default" route. The + has an empty ``pattern`` attribute, it is the "default" route. The attribute named ``view`` with the value ``.views.my_view`` is the dotted name to a *function* we write (generated by the ``bfg_routesalchemy`` template) that is given a ``request`` object diff --git a/docs/tutorials/bfgwiki2/definingviews.rst b/docs/tutorials/bfgwiki2/definingviews.rst index 775334b51..c33795883 100644 --- a/docs/tutorials/bfgwiki2/definingviews.rst +++ b/docs/tutorials/bfgwiki2/definingviews.rst @@ -22,12 +22,13 @@ callable is assumed to return a :term:`response` object. The request passed to every view that is called as the result of a route match has an attribute named ``matchdict`` that contains the -elements placed into the URL by the ``path`` of a ``route`` statement. -For instance, if a route statement in ``configure.zcml`` had the path -``:one/:two``, and the URL at ``http://example.com/foo/bar`` was -invoked, matching this path, the matchdict dictionary attached to the -request passed to the view would have a ``one`` key with the value -``foo`` and a ``two`` key with the value ``bar``. +elements placed into the URL by the ``pattern`` of a ``route`` +statement. For instance, if a route statement in ``configure.zcml`` +had the pattern ``:one/:two``, and the URL at +``http://example.com/foo/bar`` was invoked, matching this pattern, the +matchdict dictionary attached to the request passed to the view would +have a ``one`` key with the value ``foo`` and a ``two`` key with the +value ``bar``. The source code for this tutorial stage can be browsed at `docs.repoze.org `_. @@ -275,21 +276,21 @@ Note that the *ordering* of these declarations is very important. ``route`` declarations are matched in the order they're found in the ``configure.zcml`` file. -#. Add a declaration which maps the empty path (signifying the root +#. Add a declaration which maps the empty pattern (signifying the root URL) to the view named ``view_wiki`` in our ``views.py`` file with the name ``view_wiki``. This is the :term:`default view` for the wiki. -#. Add a declaration which maps the path pattern ``:pagename`` to the +#. Add a declaration which maps the pattern ``:pagename`` to the view named ``view_page`` in our ``views.py`` file with the view name ``view_page``. This is the regular view for a page. -#. Add a declaration which maps the path pattern +#. Add a declaration which maps the pattern ``:pagename/edit_page`` to the view named ``edit_page`` in our ``views.py`` file with the name ``edit_page``. This is the edit view for a page. -#. Add a declaration which maps the path pattern +#. Add a declaration which maps the pattern ``add_page/:pagename`` to the view named ``add_page`` in our ``views.py`` file with the name ``add_page``. This is the add view for a new page. diff --git a/docs/tutorials/bfgwiki2/src/authorization/tutorial/configure.zcml b/docs/tutorials/bfgwiki2/src/authorization/tutorial/configure.zcml index e51a67d70..213573d7a 100644 --- a/docs/tutorials/bfgwiki2/src/authorization/tutorial/configure.zcml +++ b/docs/tutorials/bfgwiki2/src/authorization/tutorial/configure.zcml @@ -4,38 +4,38 @@ - diff --git a/docs/tutorials/bfgwiki2/src/models/tutorial/configure.zcml b/docs/tutorials/bfgwiki2/src/models/tutorial/configure.zcml index 143f58a45..f04eec9b4 100644 --- a/docs/tutorials/bfgwiki2/src/models/tutorial/configure.zcml +++ b/docs/tutorials/bfgwiki2/src/models/tutorial/configure.zcml @@ -3,15 +3,16 @@ - diff --git a/docs/tutorials/bfgwiki2/src/views/tutorial/configure.zcml b/docs/tutorials/bfgwiki2/src/views/tutorial/configure.zcml index 7a8576a56..f86468186 100644 --- a/docs/tutorials/bfgwiki2/src/views/tutorial/configure.zcml +++ b/docs/tutorials/bfgwiki2/src/views/tutorial/configure.zcml @@ -4,32 +4,32 @@