Chris McDonough
2012-02-24 3a8cee594c3e42dd23cde72310c71aa816e3a966
Merge branch 'master' of github.com:Pylons/pyramid
4 files modified
16 ■■■■ changed files
docs/api/security.rst 4 ●●●● patch | view | raw | blame | history
docs/designdefense.rst 4 ●●●● patch | view | raw | blame | history
docs/narr/testing.rst 6 ●●●● patch | view | raw | blame | history
docs/narr/viewconfig.rst 2 ●●● patch | view | raw | blame | history
docs/api/security.rst
@@ -72,13 +72,13 @@
    The ACE "action" (the first element in an ACE e.g. ``(Allow, Everyone,
    'read')`` that means allow access.  A sequence of ACEs makes up an
    ACL.  It is a string, and it's actual value is "Allow".
    ACL.  It is a string, and its actual value is "Allow".
.. attribute:: Deny
    The ACE "action" (the first element in an ACE e.g. ``(Deny,
    'george', 'read')`` that means deny access.  A sequence of ACEs
    makes up an ACL.  It is a string, and it's actual value is "Deny".
    makes up an ACL.  It is a string, and its actual value is "Deny".
.. autoclass:: ACLDenied
   :members:
docs/designdefense.rst
@@ -1386,7 +1386,7 @@
  actually the best-case circumstance for double-imports; if a module only
  mutates itself and its contents at import time, if it is imported twice,
  that's OK, because each decorator invocation will always be mutating an
  independent copy of the object its attached to, not a shared resource like
  independent copy of the object it's attached to, not a shared resource like
  a registry in another module.  This has the effect that
  double-registrations will never be performed.
@@ -1727,7 +1727,7 @@
(Paraphrased from a real email, actually.)
Let's take this criticism point-by point.
Let's take this criticism point-by-point.
Too Complex
+++++++++++
docs/narr/testing.rst
@@ -303,12 +303,12 @@
implementations to give the code under test only enough context to run.
"Integration testing" implies another sort of testing.  In the context of a
:app:`Pyramid`, integration test, the test logic tests the functionality of
:app:`Pyramid` integration test, the test logic tests the functionality of
some code *and* its integration with the rest of the :app:`Pyramid`
framework.
In :app:`Pyramid` applications that are plugins to Pyramid, you can create an
integration test by including it's ``includeme`` function via
integration test by including its ``includeme`` function via
:meth:`pyramid.config.Configurator.include` in the test's setup code.  This
causes the entire :app:`Pyramid` environment to be set up and torn down as if
your application was running "for real".  This is a heavy-hammer way of
@@ -372,7 +372,7 @@
Functional tests test your literal application.
The below test assumes that your application's package name is ``myapp``, and
that there is view that returns an HTML body when the root URL is invoked.
that there is a view that returns an HTML body when the root URL is invoked.
It further assumes that you've added a ``tests_require`` dependency on the
``WebTest`` package within your ``setup.py`` file.  :term:`WebTest` is a
functional testing package written by Ian Bicking.
docs/narr/viewconfig.rst
@@ -900,7 +900,7 @@
configuration, Pyramid will set ``Expires`` and ``Cache-Control`` response
headers in the resulting response, causing browsers to cache the response
data for some time.  See ``http_cache`` in :ref:`nonpredicate_view_args` for
the its allowable values and what they mean.
the allowable values and what they mean.
Sometimes it's undesirable to have these headers set as the result of
returning a response from a view, even though you'd like to decorate the view