diff options
Diffstat (limited to 'docs/narr/advconfig.rst')
| -rw-r--r-- | docs/narr/advconfig.rst | 34 |
1 files changed, 22 insertions, 12 deletions
diff --git a/docs/narr/advconfig.rst b/docs/narr/advconfig.rst index f8b3ee191..30f76e456 100644 --- a/docs/narr/advconfig.rst +++ b/docs/narr/advconfig.rst @@ -115,11 +115,8 @@ allowing the circumstance to go unreported, by default Pyramid raises a running. Conflict detection happens for any kind of configuration: imperative -configuration, :term:`ZCML` configuration, or configuration that results from -the execution of a :term:`scan`. - -.. note:: If you use, ZCML, its conflict detection algorithm is described in - :ref:`zcml_conflict_detection`. +configuration or configuration that results from the execution of a +:term:`scan`. Manually Resolving Conflicts ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -274,7 +271,7 @@ If your code uses the :meth:`pyramid.config.Configurator.include` method to include external configuration, some conflicts are automatically resolved. Configuration statements that are made as the result of an "include" will be overridden by configuration statements that happen within the caller of -the "include" method. See also +the "include" method. Automatic conflict resolution supports this goal: if a user wants to reuse a Pyramid application, and they want to customize the configuration of this @@ -301,9 +298,6 @@ These are the methods of the configurator which provide conflict detection: Some other methods of the configurator also indirectly provide conflict detection, because they're implemented in terms of conflict-aware methods: -- :meth:`~pyramid.config.Configurator.add_handler`, a frontend for - ``add_route`` and ``add_view``. - - :meth:`~pyramid.config.Configurator.add_route` does a second type of conflict detection when a ``view`` parameter is passed (it calls ``add_view``). @@ -338,6 +332,23 @@ Instead, use :meth:`pyramid.config.Configuration.include`: Using ``include`` rather than calling the function directly will allow :ref:`automatic_conflict_resolution` to work. +:meth:`pyramid.config.Configuration.include` can also accept a :term:`module` +as an argument: + +.. code-block:: python + :linenos: + + import myapp + + config.include(myapp) + +For this to work properly, the ``myapp`` module must contain a callable with +the special name ``includeme``, which should perform configuration (like the +``add_routes`` callable we showed above as an example). + +:meth:`pyramid.config.Configuration.include` can also accept a :term:`dotted +Python name` to a function or a module. + .. note: See :ref:`the_include_tag` for a declarative alternative to :meth:`pyramid.config.Configurator.include`. @@ -387,9 +398,8 @@ used, two-phase configuration is disabled, and configuration statements must be ordered in dependency order. Some configuration methods, such as -:meth:`pyramid.config.Configurator.add_route` and -:meth:`pyramid.config.Configurator.add_handler` have internal ordering -constraints: they routes they imply require relative ordering. Such ordering +:meth:`pyramid.config.Configurator.add_route` have internal ordering +constraints: the routes they imply require relative ordering. Such ordering constraints are not absolved by two-phase configuration. Routes are still added in configuration execution order. |