summaryrefslogtreecommitdiff
path: root/docs/tutorials/wiki
diff options
context:
space:
mode:
authorSteve Piercy <web@stevepiercy.com>2013-01-22 00:06:20 -0800
committerSteve Piercy <web@stevepiercy.com>2013-01-22 00:06:20 -0800
commit49d8235ccca2055ca368f751037136175f80d015 (patch)
tree54a077ac4d9e1fd0601b93c5d162c6ec3c508a7f /docs/tutorials/wiki
parente266bc346f161087037647084c92c4ad26de2739 (diff)
downloadpyramid-49d8235ccca2055ca368f751037136175f80d015.tar.gz
pyramid-49d8235ccca2055ca368f751037136175f80d015.tar.bz2
pyramid-49d8235ccca2055ca368f751037136175f80d015.zip
More grammar clean up.
Diffstat (limited to 'docs/tutorials/wiki')
-rw-r--r--docs/tutorials/wiki/basiclayout.rst26
1 files changed, 13 insertions, 13 deletions
diff --git a/docs/tutorials/wiki/basiclayout.rst b/docs/tutorials/wiki/basiclayout.rst
index aab22408b..03abedbd8 100644
--- a/docs/tutorials/wiki/basiclayout.rst
+++ b/docs/tutorials/wiki/basiclayout.rst
@@ -4,7 +4,7 @@ Basic Layout
The starter files generated by the ``zodb`` scaffold are basic, but
they provide a good orientation for the high-level patterns common to most
-:term:`traversal` -based :app:`Pyramid` (and :term:`ZODB` based) projects.
+:term:`traversal` -based :app:`Pyramid` (and :term:`ZODB` -based) projects.
Application Configuration with ``__init__.py``
@@ -12,8 +12,8 @@ Application Configuration with ``__init__.py``
A directory on disk can be turned into a Python :term:`package` by containing
an ``__init__.py`` file. Even if empty, this marks a directory as a Python
-package. Our application uses ``__init__.py`` as both a package marker, as
-well as to contain application configuration code.
+package. Our application uses ``__init__.py`` both as a package marker and
+to contain application configuration code.
When you run the application using the ``pserve`` command using the
``development.ini`` generated config file, the application configuration
@@ -28,14 +28,14 @@ point happens to be the ``main`` function within the file named
#. *Lines 1-3*. Perform some dependency imports.
-#. *Lines 6-8* Define a root factory for our Pyramid application.
+#. *Lines 6-8*. Define a root factory for our Pyramid application.
#. *Line 14*. We construct a :term:`Configurator` with a :term:`root
factory` and the settings keywords parsed by :term:`PasteDeploy`. The root
factory is named ``root_factory``.
-#. *Line 15*. Register a 'static view' which answers requests which start
- with URL path ``/static`` using the
+#. *Line 15*. Register a "static view" which answers requests whose URL path
+ start with ``/static`` using the
:meth:`pyramid.config.Configurator.add_static_view method`. This
statement registers a view that will serve up static assets, such as CSS
and image files, for us, in this case, at
@@ -44,16 +44,16 @@ point happens to be the ``main`` function within the file named
will be ``/static``. The second argument of this tag is the "path",
which is a relative :term:`asset specification`, so it finds the resources
it should serve within the ``static`` directory inside the ``tutorial``
- package. The scaffold could have alternately used an *absolute* asset
- specification as the path (``tutorial:static``) but it does not.
+ package. Alternatively the scaffold could have used an *absolute* asset
+ specification as the path (``tutorial:static``).
#. *Line 16*. Perform a :term:`scan`. A scan will find :term:`configuration
- decoration`, such as view configuration decorators (e.g. ``@view_config``)
+ decoration`, such as view configuration decorators (e.g., ``@view_config``)
in the source code of the ``tutorial`` package and will take actions based
on these decorators. We don't pass any arguments to
:meth:`~pyramid.config.Configurator.scan`, which implies that the scan
should take place in the current package (in this case, ``tutorial``).
- The scaffold could have equivalently said ``config.scan('tutorial')`` but
+ The scaffold could have equivalently said ``config.scan('tutorial')``, but
it chose to omit the package name argument.
#. *Line 17*. Use the
@@ -70,7 +70,7 @@ tree represents the site structure, but it *also* represents the
:term:`domain model` of the application, because each resource is a node
stored persistently in a :term:`ZODB` database. The ``models.py`` file is
where the ``zodb`` scaffold put the classes that implement our
-resource objects, each of which happens also to be a domain model object.
+resource objects, each of which also happens to be a domain model object.
Here is the source for ``models.py``:
@@ -79,7 +79,7 @@ Here is the source for ``models.py``:
:language: py
#. *Lines 4-5*. The ``MyModel`` :term:`resource` class is implemented here.
- Instances of this class will be capable of being persisted in :term:`ZODB`
+ Instances of this class are capable of being persisted in :term:`ZODB`
because the class inherits from the
:class:`persistent.mapping.PersistentMapping` class. The ``__parent__``
and ``__name__`` are important parts of the :term:`traversal` protocol.
@@ -137,7 +137,7 @@ Let's try to understand the components in this module:
indeed if you look in the ``templates`` directory of this package, you'll
see a ``mytemplate.pt`` template file, which renders the default home page
of the generated project. This asset specification is *relative* (to the
- view.py's current package). We could have alternately an used the
+ view.py's current package). Alternatively we could have used the
absolute asset specification ``tutorial:templates/mytemplate.pt``, but
chose to use the relative version.