Merge branch 'master' of github.com:Pylons/pyramid
| | |
| | | |
| | | 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: |
| | |
| | | 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. |
| | | |
| | |
| | | |
| | | (Paraphrased from a real email, actually.) |
| | | |
| | | Let's take this criticism point-by point. |
| | | Let's take this criticism point-by-point. |
| | | |
| | | Too Complex |
| | | +++++++++++ |
| | |
| | | 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 |
| | |
| | | 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. |
| | |
| | | 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 |