summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorChris McDonough <chrism@agendaless.com>2009-11-22 08:46:29 +0000
committerChris McDonough <chrism@agendaless.com>2009-11-22 08:46:29 +0000
commit84de36364ec78b7651634add5aaf972ec343f29e (patch)
tree355ebe124d7b91ac3a449e12349dd1927416f8dc /docs
parent6012899c7d7bd4a5ffd64f0b9cede9639610ef41 (diff)
downloadpyramid-84de36364ec78b7651634add5aaf972ec343f29e.tar.gz
pyramid-84de36364ec78b7651634add5aaf972ec343f29e.tar.bz2
pyramid-84de36364ec78b7651634add5aaf972ec343f29e.zip
Rendering.
Diffstat (limited to 'docs')
-rw-r--r--docs/narr/configuration.rst54
1 files changed, 27 insertions, 27 deletions
diff --git a/docs/narr/configuration.rst b/docs/narr/configuration.rst
index b3ac60e24..d60f613d9 100644
--- a/docs/narr/configuration.rst
+++ b/docs/narr/configuration.rst
@@ -3,19 +3,6 @@
Creating Your First :mod:`repoze.bfg` Application
=================================================
-The majority of the logic in any web application is completely
-application-specific. For example, the body of a web page served by
-one web application might be a representation of the contents of an
-accounting ledger, while the content of of a web page served by
-another might be a listing of songs. These applications obviously
-might not service the same set of customers. However, both the
-ledger-serving and song-serving applications can be written using
-:mod:`repoze.bfg`, because :mod:`repoze.bfg` is a very general
-*framework* which can be used to create all kinds of web
-applications. As a framework, the primary job of :mod:`repoze.bfg` is
-to make it easier for a developer to create an arbitrary web
-application.
-
.. sidebar:: Frameworks vs. Libraries
A *framework* differs from a *library* in one very important way:
@@ -38,6 +25,19 @@ application.
requirements. :mod:`repoze.bfg` is a framework that fits a large
set of assumptions in the domain of web application creation.
+The majority of the logic in any web application is completely
+application-specific. For example, the body of a web page served by
+one web application might be a representation of the contents of an
+accounting ledger, while the content of of a web page served by
+another might be a listing of songs. These applications obviously
+might not service the same set of customers. However, both the
+ledger-serving and song-serving applications can be written using
+:mod:`repoze.bfg`, because :mod:`repoze.bfg` is a very general
+*framework* which can be used to create all kinds of web
+applications. As a framework, the primary job of :mod:`repoze.bfg` is
+to make it easier for a developer to create an arbitrary web
+application.
+
From the perspective of its authors, each deployment of an application
written using :mod:`repoze.bfg` implies a specific *configuration* of
the framework itself. For example, a song-serving application might
@@ -46,20 +46,20 @@ serving application might plug code that manages accounting information.
:mod:`repoze.bfg` refers to the way in which code is plugged in to it
for a specific deployment as "configuration".
-This way of thinking may sound a bit strange. Many people think of
-"configuration" as coarse knobs 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 that is read at application
-startup time as "configuration". :mod:`repoze.bfg` goes a bit further
-than that, because it uses standardized ways of plugging the code into
-the framework, and these can be expressed via configuration as well.
-Thus, when you plug code into it in various ways, you are indeed
-"configuring" :mod:`repoze.bfg` for the purpose of creating an
-application deployment. From the perspective of a developer creating
-an application using :mod:`repoze.bfg`, performing the tasks that
-:mod:`repoze.bfg` calls "configuration" might alternately be referred
-to as "wiring" or "plumbing". :mod:`repoze.bfg` refers to it as
-"configuration", for lack of a more fitting term.
+Many people think of "configuration" as coarse knobs 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
+that is read at application startup time as "configuration".
+:mod:`repoze.bfg` goes a bit further than that, because it uses
+standardized ways of plugging code into the framework, and these can
+be expressed via configuration as well. Thus, when you plug code into
+it in various ways, you are indeed "configuring" :mod:`repoze.bfg` for
+the purpose of creating an application deployment. From the
+perspective of a developer creating an application using
+:mod:`repoze.bfg`, performing the tasks that :mod:`repoze.bfg` calls
+"configuration" might alternately be referred to as "wiring" or
+"plumbing". :mod:`repoze.bfg` refers to it as "configuration", for
+lack of a more fitting term.
There are a number of different mechanisms you may use to configure
:mod:`repoze.bfg` to create an application: *imperative* configuration