From 4e1199fdb3219ed7ed3635f8ed96fb0cff18abe1 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Mon, 11 Jul 2011 04:35:53 -0400 Subject: simplify --- docs/narr/configuration.rst | 44 ++++++++++++++++++++------------------------ 1 file changed, 20 insertions(+), 24 deletions(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index 6360dc574..4c2870562 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -23,6 +23,10 @@ standardized ways that code gets plugged into a deployment of the framework itself. When you plug code into the :app:`Pyramid` framework, you are "configuring" :app:`Pyramid` to create a particular application. +There are two ways to configure a :app:`Pyramid` application: +:term:`imperative configuration` and :term:`declarative configuration`. Both +are described below. + .. index:: single: imperative configuration @@ -31,8 +35,9 @@ itself. When you plug code into the :app:`Pyramid` framework, you are Imperative Configuration ------------------------ -Here's one of the simplest :app:`Pyramid` applications, configured -imperatively: +"Imperative configuration" just means configuration done by Python +statements, one after the next. Here's one of the simplest :app:`Pyramid` +applications, configured imperatively: .. code-block:: python :linenos: @@ -64,19 +69,17 @@ including conditionals, can be employed in this mode of configuration. .. _decorations_and_code_scanning: -Configuration Decorations and Code Scanning -------------------------------------------- +Declarative Configuration +------------------------- -A different mode of configuration gives more *locality of reference* to a -:term:`configuration declaration`. It's sometimes painful to have all -configuration done in imperative code, because often the code for a single -application may live in many files. If the configuration is centralized in -one place, you'll need to have at least two files open at once to see the -"big picture": the file that represents the configuration, and the file that -contains the implementation objects referenced by the configuration. To -avoid this, :app:`Pyramid` allows you to insert :term:`configuration -decoration` statements very close to code that is referred to by the -declaration itself. For example: +It's sometimes painful to have all configuration done by imperative code, +because often the code for a single application may live in many files. If +the configuration is centralized in one place, you'll need to have at least +two files open at once to see the "big picture": the file that represents the +configuration, and the file that contains the implementation objects +referenced by the configuration. To avoid this, :app:`Pyramid` allows you to +insert :term:`configuration decoration` statements very close to code that is +referred to by the declaration itself. For example: .. code-block:: python :linenos: @@ -135,6 +138,9 @@ the scanner, a set of calls are made to a :term:`Configurator` on your behalf: these calls replace the need to add imperative configuration statements that don't live near the code being configured. +The combination of :term:`configuration decoration` and the invocation of a +:term:`scan` is collectively known as :term:`declarative configuration`. + In the example above, the scanner translates the arguments to :class:`~pyramid.view.view_config` into a call to the :meth:`pyramid.config.Configurator.add_view` method, effectively: @@ -145,13 +151,3 @@ In the example above, the scanner translates the arguments to config.add_view(hello) -Declarative Configuration -------------------------- - -A third mode of configuration can be employed when you create a -:app:`Pyramid` application named *declarative configuration*. This mode uses -an XML language known as :term:`ZCML` to represent configuration statements -rather than Python. ZCML is not built-in to Pyramid, but almost everything -that can be configured imperatively can also be configured via ZCML if you -install the :term:`pyramid_zcml` package. - -- cgit v1.2.3 From 7c48ff7bde21fda813ce74a7691c89bedd2b54cc Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Mon, 11 Jul 2011 23:58:57 -0400 Subject: simplify --- docs/narr/configuration.rst | 25 +++++++++---------------- 1 file changed, 9 insertions(+), 16 deletions(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index 4c2870562..3ecb4b06a 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -6,22 +6,15 @@ Application Configuration ========================= -Each deployment of an application written using :app:`Pyramid` implies a -specific *configuration* of the framework itself. For example, an -application which serves up MP3 files for your listening enjoyment might plug -code into the framework that manages song files, while an application that -manages corporate data might plug in code that manages accounting -information. The way in which code is plugged in to :app:`Pyramid` for a -specific application is referred to as "configuration". - -Most people understand "configuration" as coarse settings that inform the -high-level operation of a specific application deployment. For instance, -it's easy to think of the values implied by a ``.ini`` file parsed at -application startup time as "configuration". :app:`Pyramid` extends this -pattern to application development, using the term "configuration" to express -standardized ways that code gets plugged into a deployment of the framework -itself. When you plug code into the :app:`Pyramid` framework, you are -"configuring" :app:`Pyramid` to create a particular application. +The way in which code is plugged in to :app:`Pyramid` for a specific +application is referred to as "configuration". Most people understand +"configuration" as coarse settings that inform the high-level operation of a +specific application deployment. For instance, it's easy to think of the +values implied by a ``.ini`` file parsed at application startup time as +"configuration". However, :app:`Pyramid` also uses the word "configuration" +to express standardized ways that code gets plugged into a deployment of the +framework itself. When you plug code into the :app:`Pyramid` framework, you +are "configuring" :app:`Pyramid` to create a particular application. There are two ways to configure a :app:`Pyramid` application: :term:`imperative configuration` and :term:`declarative configuration`. Both -- cgit v1.2.3 From be9bbff6440750e56a73f534bc09511ef5d2b8b4 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Wed, 20 Jul 2011 07:31:33 -0400 Subject: use less awkward language --- docs/narr/configuration.rst | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index 3ecb4b06a..dacf09f18 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -6,15 +6,16 @@ Application Configuration ========================= -The way in which code is plugged in to :app:`Pyramid` for a specific -application is referred to as "configuration". Most people understand -"configuration" as coarse settings that inform the high-level operation of a -specific application deployment. For instance, it's easy to think of the -values implied by a ``.ini`` file parsed at application startup time as -"configuration". However, :app:`Pyramid` also uses the word "configuration" -to express standardized ways that code gets plugged into a deployment of the -framework itself. When you plug code into the :app:`Pyramid` framework, you -are "configuring" :app:`Pyramid` to create a particular application. +Most people already understand "configuration" as settings that influence the +operation of an application. For instance, it's easy to think of the values +in a ``.ini`` file parsed at application startup time as "configuration". +However, if you're reasonably open-minded, it's easy to think of *code* as +configuration too. Since Pyramid, like most other web application platforms, +is a *framework*, it calls into code that you write (as opposed to a +*library*, which is code that exists purely for your to call). The act of +plugging application code that you've written into :app:`Pyramid` is also +referred to within this documentation as "configuration"; you are configuring +:app:`Pyramid` to call the code that makes up your application. There are two ways to configure a :app:`Pyramid` application: :term:`imperative configuration` and :term:`declarative configuration`. Both @@ -144,3 +145,10 @@ In the example above, the scanner translates the arguments to config.add_view(hello) +Summary +------- + +There are two ways to configure a :app:`Pyramid` application: declaratively +and imperatively. You can choose the mode you're most comfortable with; both +are completely equivalent. Examples in this documentation will use both +modes interchangeably. -- cgit v1.2.3 From 87a689d71191a175ee20e52701a9e802548f91a6 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Wed, 20 Jul 2011 07:32:01 -0400 Subject: typo --- docs/narr/configuration.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index dacf09f18..597d48b09 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -12,7 +12,7 @@ in a ``.ini`` file parsed at application startup time as "configuration". However, if you're reasonably open-minded, it's easy to think of *code* as configuration too. Since Pyramid, like most other web application platforms, is a *framework*, it calls into code that you write (as opposed to a -*library*, which is code that exists purely for your to call). The act of +*library*, which is code that exists purely for you to call). The act of plugging application code that you've written into :app:`Pyramid` is also referred to within this documentation as "configuration"; you are configuring :app:`Pyramid` to call the code that makes up your application. -- cgit v1.2.3 From 10f1b5c35072c5499f3504dc261fb3c67a90c70d Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Fri, 16 Dec 2011 04:54:09 -0500 Subject: stamp out paste.httpserver usage --- docs/narr/configuration.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index 597d48b09..37122e382 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -36,7 +36,7 @@ applications, configured imperatively: .. code-block:: python :linenos: - from paste.httpserver import serve + from wsgiref.simple_server import make_server from pyramid.config import Configurator from pyramid.response import Response @@ -46,8 +46,8 @@ applications, configured imperatively: if __name__ == '__main__': config = Configurator() config.add_view(hello_world) - app = config.make_wsgi_app() - serve(app, host='0.0.0.0') + server = make_server('0.0.0.0', 8080, app) + server.serve_forever() We won't talk much about what this application does yet. Just note that the "configuration' statements take place underneath the ``if __name__ == @@ -105,7 +105,7 @@ in a package and its subpackages. For example: .. code-block:: python :linenos: - from paste.httpserver import serve + from wsgiref.simple_server import make_server from pyramid.response import Response from pyramid.view import view_config @@ -118,7 +118,8 @@ in a package and its subpackages. For example: config = Configurator() config.scan() app = config.make_wsgi_app() - serve(app, host='0.0.0.0') + server = make_server('0.0.0.0', 8080, app) + server.serve_forever() The scanning machinery imports each module and subpackage in a package or module recursively, looking for special attributes attached to objects -- cgit v1.2.3 From 64497edc64a153815c54b254bf64a46ac21a6ac7 Mon Sep 17 00:00:00 2001 From: Michael Merickel Date: Thu, 5 Jan 2012 03:46:18 -0600 Subject: Fixed a couple docs bugs reported by davidfung. --- docs/narr/configuration.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index 37122e382..cd3dab099 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -46,6 +46,7 @@ applications, configured imperatively: if __name__ == '__main__': config = Configurator() config.add_view(hello_world) + app = config.make_wsgi_app() server = make_server('0.0.0.0', 8080, app) server.serve_forever() @@ -106,6 +107,7 @@ in a package and its subpackages. For example: :linenos: from wsgiref.simple_server import make_server + from pyramid.config import Configurator from pyramid.response import Response from pyramid.view import view_config -- cgit v1.2.3 From cb659d206463607b5387878a857ead770c4df8cc Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 6 Feb 2013 23:25:42 +0200 Subject: displaying lineno for 1-line snippet is overkill --- docs/narr/configuration.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index cd3dab099..820dda269 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -144,7 +144,6 @@ In the example above, the scanner translates the arguments to .. ignore-next-block .. code-block:: python - :linenos: config.add_view(hello) -- cgit v1.2.3 From 6a4c6cb1c6ebe148e948726ddf668a3c2aa6c86c Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Wed, 6 Feb 2013 23:38:01 +0200 Subject: no need for a 'topic' directive --- docs/narr/configuration.rst | 44 +++++++++++++++++++++----------------------- 1 file changed, 21 insertions(+), 23 deletions(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index cd3dab099..4370367c0 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -99,29 +99,27 @@ available for a :term:`scan` to find it later. A :term:`scan` of a :term:`module` or a :term:`package` and its subpackages for decorations happens when the :meth:`pyramid.config.Configurator.scan` method is invoked: scanning implies searching for configuration declarations -in a package and its subpackages. For example: - -.. topic:: Starting A Scan - - .. code-block:: python - :linenos: - - from wsgiref.simple_server import make_server - from pyramid.config import Configurator - from pyramid.response import Response - from pyramid.view import view_config - - @view_config() - def hello(request): - return Response('Hello') - - if __name__ == '__main__': - from pyramid.config import Configurator - config = Configurator() - config.scan() - app = config.make_wsgi_app() - server = make_server('0.0.0.0', 8080, app) - server.serve_forever() +in a package and its subpackages. For example:: + +.. code-block:: python + :linenos: + + from wsgiref.simple_server import make_server + from pyramid.config import Configurator + from pyramid.response import Response + from pyramid.view import view_config + + @view_config() + def hello(request): + return Response('Hello') + + if __name__ == '__main__': + from pyramid.config import Configurator + config = Configurator() + config.scan() + app = config.make_wsgi_app() + server = make_server('0.0.0.0', 8080, app) + server.serve_forever() The scanning machinery imports each module and subpackage in a package or module recursively, looking for special attributes attached to objects -- cgit v1.2.3 From c7e558156dff1c8fdc96fe0382e48ca4d5bf8205 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 8 Feb 2013 20:48:08 +0200 Subject: fix a Sphinx warning --- docs/narr/configuration.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index cc26c55d9..6f82baf32 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -99,7 +99,7 @@ available for a :term:`scan` to find it later. A :term:`scan` of a :term:`module` or a :term:`package` and its subpackages for decorations happens when the :meth:`pyramid.config.Configurator.scan` method is invoked: scanning implies searching for configuration declarations -in a package and its subpackages. For example:: +in a package and its subpackages. For example: .. code-block:: python :linenos: -- cgit v1.2.3 From 1ad8de2b9032b5a452b75274b8f908645c732e57 Mon Sep 17 00:00:00 2001 From: Tshepang Lekhonkhobe Date: Fri, 22 Mar 2013 17:24:32 +0200 Subject: remove unused ignore-next-block directive --- docs/narr/configuration.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index 6f82baf32..f7a69d613 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -140,7 +140,6 @@ In the example above, the scanner translates the arguments to :class:`~pyramid.view.view_config` into a call to the :meth:`pyramid.config.Configurator.add_view` method, effectively: -.. ignore-next-block .. code-block:: python config.add_view(hello) -- cgit v1.2.3 From cef139b9c2f163694968ae5b7efe7eae07e72c04 Mon Sep 17 00:00:00 2001 From: bobby Date: Wed, 23 Apr 2014 23:04:00 -0700 Subject: Typo found in second Declarative code block There were two import statements for Configurator. I removed the second import statement in the "__main__" since most of the documentation declares all imports on the top of the source. modified: configuration.rst --- docs/narr/configuration.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index f7a69d613..52615533d 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -114,7 +114,6 @@ in a package and its subpackages. For example: return Response('Hello') if __name__ == '__main__': - from pyramid.config import Configurator config = Configurator() config.scan() app = config.make_wsgi_app() -- cgit v1.2.3 From 1a768e3d45594d2458c379bcd55d6f1478ef3281 Mon Sep 17 00:00:00 2001 From: "Karl O. Pinc" Date: Fri, 8 Aug 2014 23:22:24 -0500 Subject: Link to .ini file description in configuration chapter. The Startup chapter describes a Pyramid application's .ini file. This is now a seealso in the Configuration chapter. --- docs/narr/configuration.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index 52615533d..f7fa94daf 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -17,6 +17,10 @@ plugging application code that you've written into :app:`Pyramid` is also referred to within this documentation as "configuration"; you are configuring :app:`Pyramid` to call the code that makes up your application. +.. seealso:: + For information on ``.ini`` files for Pyramid applications see the + :ref:`startup_chapter` chapter. + There are two ways to configure a :app:`Pyramid` application: :term:`imperative configuration` and :term:`declarative configuration`. Both are described below. -- cgit v1.2.3 From 87ae607687f94ef73a9a4a24409515cc08a2db91 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Sun, 4 Oct 2015 04:08:33 -0700 Subject: grammar (cherry picked from commit 961dcb8) (cherry picked from commit eb74c4d) --- docs/narr/configuration.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index f7fa94daf..c1457fce5 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -57,7 +57,7 @@ applications, configured imperatively: We won't talk much about what this application does yet. Just note that the "configuration' statements take place underneath the ``if __name__ == '__main__':`` stanza in the form of method calls on a :term:`Configurator` -object (e.g. ``config.add_view(...)``). These statements take place one +object (e.g., ``config.add_view(...)``). These statements take place one after the other, and are executed in order, so the full power of Python, including conditionals, can be employed in this mode of configuration. @@ -133,7 +133,7 @@ instance method. Once scanning is invoked, and :term:`configuration decoration` is found by the scanner, a set of calls are made to a :term:`Configurator` on your -behalf: these calls replace the need to add imperative configuration +behalf. These calls replace the need to add imperative configuration statements that don't live near the code being configured. The combination of :term:`configuration decoration` and the invocation of a @@ -151,6 +151,6 @@ Summary ------- There are two ways to configure a :app:`Pyramid` application: declaratively -and imperatively. You can choose the mode you're most comfortable with; both -are completely equivalent. Examples in this documentation will use both +and imperatively. You can choose the mode with which you're most comfortable; +both are completely equivalent. Examples in this documentation will use both modes interchangeably. -- cgit v1.2.3 From 553a948fe67e4c761ce0a9da85e898db7c2b6625 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Thu, 8 Oct 2015 23:34:02 -0700 Subject: wrap 79 cols --- docs/narr/configuration.rst | 92 ++++++++++++++++++++++----------------------- 1 file changed, 45 insertions(+), 47 deletions(-) (limited to 'docs/narr/configuration.rst') diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst index c1457fce5..cde166b21 100644 --- a/docs/narr/configuration.rst +++ b/docs/narr/configuration.rst @@ -3,27 +3,26 @@ .. _configuration_narr: -Application Configuration +Application Configuration ========================= Most people already understand "configuration" as settings that influence the -operation of an application. For instance, it's easy to think of the values -in a ``.ini`` file parsed at application startup time as "configuration". -However, if you're reasonably open-minded, it's easy to think of *code* as -configuration too. Since Pyramid, like most other web application platforms, -is a *framework*, it calls into code that you write (as opposed to a -*library*, which is code that exists purely for you to call). The act of -plugging application code that you've written into :app:`Pyramid` is also -referred to within this documentation as "configuration"; you are configuring +operation of an application. For instance, it's easy to think of the values in +a ``.ini`` file parsed at application startup time as "configuration". However, +if you're reasonably open-minded, it's easy to think of *code* as configuration +too. Since Pyramid, like most other web application platforms, is a +*framework*, it calls into code that you write (as opposed to a *library*, +which is code that exists purely for you to call). The act of plugging +application code that you've written into :app:`Pyramid` is also referred to +within this documentation as "configuration"; you are configuring :app:`Pyramid` to call the code that makes up your application. .. seealso:: For information on ``.ini`` files for Pyramid applications see the :ref:`startup_chapter` chapter. -There are two ways to configure a :app:`Pyramid` application: -:term:`imperative configuration` and :term:`declarative configuration`. Both -are described below. +There are two ways to configure a :app:`Pyramid` application: :term:`imperative +configuration` and :term:`declarative configuration`. Both are described below. .. index:: single: imperative configuration @@ -33,9 +32,9 @@ are described below. Imperative Configuration ------------------------ -"Imperative configuration" just means configuration done by Python -statements, one after the next. Here's one of the simplest :app:`Pyramid` -applications, configured imperatively: +"Imperative configuration" just means configuration done by Python statements, +one after the next. Here's one of the simplest :app:`Pyramid` applications, +configured imperatively: .. code-block:: python :linenos: @@ -57,9 +56,9 @@ applications, configured imperatively: We won't talk much about what this application does yet. Just note that the "configuration' statements take place underneath the ``if __name__ == '__main__':`` stanza in the form of method calls on a :term:`Configurator` -object (e.g., ``config.add_view(...)``). These statements take place one -after the other, and are executed in order, so the full power of Python, -including conditionals, can be employed in this mode of configuration. +object (e.g., ``config.add_view(...)``). These statements take place one after +the other, and are executed in order, so the full power of Python, including +conditionals, can be employed in this mode of configuration. .. index:: single: view_config @@ -72,13 +71,13 @@ Declarative Configuration ------------------------- It's sometimes painful to have all configuration done by imperative code, -because often the code for a single application may live in many files. If -the configuration is centralized in one place, you'll need to have at least -two files open at once to see the "big picture": the file that represents the -configuration, and the file that contains the implementation objects -referenced by the configuration. To avoid this, :app:`Pyramid` allows you to -insert :term:`configuration decoration` statements very close to code that is -referred to by the declaration itself. For example: +because often the code for a single application may live in many files. If the +configuration is centralized in one place, you'll need to have at least two +files open at once to see the "big picture": the file that represents the +configuration, and the file that contains the implementation objects referenced +by the configuration. To avoid this, :app:`Pyramid` allows you to insert +:term:`configuration decoration` statements very close to code that is referred +to by the declaration itself. For example: .. code-block:: python :linenos: @@ -90,20 +89,19 @@ referred to by the declaration itself. For example: def hello(request): return Response('Hello') -The mere existence of configuration decoration doesn't cause any -configuration registration to be performed. Before it has any effect on the -configuration of a :app:`Pyramid` application, a configuration decoration -within application code must be found through a process known as a -:term:`scan`. +The mere existence of configuration decoration doesn't cause any configuration +registration to be performed. Before it has any effect on the configuration of +a :app:`Pyramid` application, a configuration decoration within application +code must be found through a process known as a :term:`scan`. For example, the :class:`pyramid.view.view_config` decorator in the code -example above adds an attribute to the ``hello`` function, making it -available for a :term:`scan` to find it later. +example above adds an attribute to the ``hello`` function, making it available +for a :term:`scan` to find it later. -A :term:`scan` of a :term:`module` or a :term:`package` and its subpackages -for decorations happens when the :meth:`pyramid.config.Configurator.scan` -method is invoked: scanning implies searching for configuration declarations -in a package and its subpackages. For example: +A :term:`scan` of a :term:`module` or a :term:`package` and its subpackages for +decorations happens when the :meth:`pyramid.config.Configurator.scan` method is +invoked: scanning implies searching for configuration declarations in a package +and its subpackages. For example: .. code-block:: python :linenos: @@ -125,16 +123,16 @@ in a package and its subpackages. For example: server.serve_forever() The scanning machinery imports each module and subpackage in a package or -module recursively, looking for special attributes attached to objects -defined within a module. These special attributes are typically attached to -code via the use of a :term:`decorator`. For example, the +module recursively, looking for special attributes attached to objects defined +within a module. These special attributes are typically attached to code via +the use of a :term:`decorator`. For example, the :class:`~pyramid.view.view_config` decorator can be attached to a function or instance method. -Once scanning is invoked, and :term:`configuration decoration` is found by -the scanner, a set of calls are made to a :term:`Configurator` on your -behalf. These calls replace the need to add imperative configuration -statements that don't live near the code being configured. +Once scanning is invoked, and :term:`configuration decoration` is found by the +scanner, a set of calls are made to a :term:`Configurator` on your behalf. +These calls replace the need to add imperative configuration statements that +don't live near the code being configured. The combination of :term:`configuration decoration` and the invocation of a :term:`scan` is collectively known as :term:`declarative configuration`. @@ -150,7 +148,7 @@ In the example above, the scanner translates the arguments to Summary ------- -There are two ways to configure a :app:`Pyramid` application: declaratively -and imperatively. You can choose the mode with which you're most comfortable; -both are completely equivalent. Examples in this documentation will use both -modes interchangeably. +There are two ways to configure a :app:`Pyramid` application: declaratively and +imperatively. You can choose the mode with which you're most comfortable; both +are completely equivalent. Examples in this documentation will use both modes +interchangeably. -- cgit v1.2.3