diff options
Diffstat (limited to 'docs/narr')
| -rw-r--r-- | docs/narr/hellotraversal.py | 22 | ||||
| -rw-r--r-- | docs/narr/hellotraversal.rst | 69 | ||||
| -rw-r--r-- | docs/narr/introduction.rst | 2 | ||||
| -rw-r--r-- | docs/narr/muchadoabouttraversal.rst | 4 | ||||
| -rw-r--r-- | docs/narr/project.rst | 6 | ||||
| -rw-r--r-- | docs/narr/security.rst | 69 | ||||
| -rw-r--r-- | docs/narr/traversal.rst | 7 | ||||
| -rw-r--r-- | docs/narr/viewconfig.rst | 6 | ||||
| -rw-r--r-- | docs/narr/views.rst | 2 |
9 files changed, 140 insertions, 47 deletions
diff --git a/docs/narr/hellotraversal.py b/docs/narr/hellotraversal.py new file mode 100644 index 000000000..1ef7525e6 --- /dev/null +++ b/docs/narr/hellotraversal.py @@ -0,0 +1,22 @@ +from wsgiref.simple_server import make_server +from pyramid.config import Configurator +from pyramid.response import Response + +class Resource(dict): + pass + +def get_root(request): + return Resource({'a': Resource({'b': Resource({'c': Resource()})})}) + +def hello_world_of_resources(context, request): + output = "Here's a resource and its children: %s" % context + return Response(output) + +if __name__ == '__main__': + config = Configurator(root_factory=get_root) + config.add_view(hello_world_of_resources, context=Resource) + app = config.make_wsgi_app() + server = make_server('0.0.0.0', 8080, app) + server.serve_forever() + + diff --git a/docs/narr/hellotraversal.rst b/docs/narr/hellotraversal.rst new file mode 100644 index 000000000..142c24f54 --- /dev/null +++ b/docs/narr/hellotraversal.rst @@ -0,0 +1,69 @@ +.. _hello_traversal_chapter: + +Hello Traversal World +====================== + + +.. index:: + single: traversal quick example + +Traversal is an alternative to URL dispatch which allows Pyramid +applications to map URLs to code. + +If code speaks louder than words, maybe this will help. Here is a +single-file Pyramid application that uses traversal: + +.. literalinclude:: hellotraversal.py + :linenos: + +You may notice that this application is intentionally very similar to +the "hello world" app from :doc:`firstapp`. + +On lines 5-6, we create a trivial :term:`resource` class that's just a +dictionary subclass. + +On lines 8-9, we hard-code a :term:`resource tree` in our :term:`root +factory` function. + +On lines 11-13 we define a single :term:`view callable` that can +display a single instance of our Resource class, passed as the +``context`` argument. + +The rest of the file sets up and serves our pyramid WSGI app. Line 18 +is where our view gets configured for use whenever the traversal ends +with an instance of our Resource class. + +Interestingly, there are no URLs explicitly configured in this +application. Instead, the URL space is defined entirely by the keys in +the resource tree. + +Example requests +---------------- + +If this example is running on http://localhost:8080, and the user +browses to http://localhost:8080/a/b, Pyramid will call +``get_root(request)`` to get the root resource, then traverse the tree +from there by key; starting from the root, it will find the child with +key ``"a"``, then its child with key ``"b"``; then use that as the +``context`` argument for calling ``hello_world_of_resources``. + +Or, if the user browses to http://localhost:8080/ , Pyramid will +stop at the root - the outermost Resource instance, in this case - and +use that as the ``context`` argument to the same view. + +Or, if the user browses to a key that doesn't exist in this resource +tree, like http://localhost:8080/xyz or +http://localhost:8080/a/b/c/d, the traversal will end by raising a +KeyError, and Pyramid will turn that into a 404 HTTP response. + +A more complicated application could have many types of resources, +with different view callables defined for each type, and even multiple +views for each type. + +See Also +--------- + +Full technical details may be found in :doc:`traversal`. + +For more about *why* you might use traversal, see :doc:`muchadoabouttraversal`. + diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst index 7c6ad00f3..92955aafd 100644 --- a/docs/narr/introduction.rst +++ b/docs/narr/introduction.rst @@ -597,7 +597,7 @@ content management systems and document management systems. Traversal also lend systems that require very granular security ("Bob can edit *this* document" as opposed to "Bob can edit documents"). -Example: :ref:`much_ado_about_traversal_chapter`. +Example: :ref:`hello_traversal_chapter` and :ref:`much_ado_about_traversal_chapter`. Tweens ~~~~~~ diff --git a/docs/narr/muchadoabouttraversal.rst b/docs/narr/muchadoabouttraversal.rst index 4a249ed0d..40d498391 100644 --- a/docs/narr/muchadoabouttraversal.rst +++ b/docs/narr/muchadoabouttraversal.rst @@ -4,6 +4,8 @@ Much Ado About Traversal ======================== +(Or, why you should care about it) + .. note:: This chapter was adapted, with permission, from a blog post by `Rob @@ -15,7 +17,7 @@ Traversal is an alternative to :term:`URL dispatch` which allows .. note:: - Ex-Zope users whom are already familiar with traversal and view lookup + Ex-Zope users who are already familiar with traversal and view lookup conceptually may want to skip directly to the :ref:`traversal_chapter` chapter, which discusses technical details. This chapter is mostly aimed at people who have previous :term:`Pylons` experience or experience in diff --git a/docs/narr/project.rst b/docs/narr/project.rst index 5696b0b73..ea0045ca7 100644 --- a/docs/narr/project.rst +++ b/docs/narr/project.rst @@ -118,11 +118,11 @@ your application, or install your application for deployment or development. A ``.ini`` file named ``development.ini`` will be created in the project directory. You will use this ``.ini`` file to configure a server, to run -your application, and to debug your application. It sports configuration +your application, and to debug your application. It contains configuration that enables an interactive debugger and settings optimized for development. Another ``.ini`` file named ``production.ini`` will also be created in the -project directory. It sports configuration that disables any interactive +project directory. It contains configuration that disables any interactive debugger (to prevent inappropriate access and disclosure), and turns off a number of debugging settings. You can use this file to put your application into production. @@ -709,7 +709,7 @@ also informs Python that the directory which contains it is a *package*. #. Line 1 imports the :term:`Configurator` class from :mod:`pyramid.config` that we use later. -#. Lines 3-16 define a function named ``main`` that returns a :app:`Pyramid` +#. Lines 3-10 define a function named ``main`` that returns a :app:`Pyramid` WSGI application. This function is meant to be called by the :term:`PasteDeploy` framework as a result of running ``pserve``. diff --git a/docs/narr/security.rst b/docs/narr/security.rst index 1ad35b961..07ec0f21e 100644 --- a/docs/narr/security.rst +++ b/docs/narr/security.rst @@ -73,16 +73,15 @@ to enable an authorization policy. Enabling an Authorization Policy Imperatively ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Passing an ``authorization_policy`` argument to the constructor of the -:class:`~pyramid.config.Configurator` class enables an -authorization policy. +Use the :meth:`~pyramid.config.Configurator.set_authorization_policy` method +of the :class:`~pyramid.config.Configurator` to enable an authorization +policy. -You must also enable an :term:`authentication policy` in order to -enable the authorization policy. This is because authorization, in -general, depends upon authentication. Use the -``authentication_policy`` argument to the -:class:`~pyramid.config.Configurator` class during -application setup to specify an authentication policy. +You must also enable an :term:`authentication policy` in order to enable the +authorization policy. This is because authorization, in general, depends +upon authentication. Use the +:meth:`~pyramid.config.Configurator.set_authentication_policy` and method +during application setup to specify the authentication policy. For example: @@ -95,13 +94,14 @@ For example: from pyramid.authorization import ACLAuthorizationPolicy authentication_policy = AuthTktAuthenticationPolicy('seekrit') authorization_policy = ACLAuthorizationPolicy() - config = Configurator(authentication_policy=authentication_policy, - authorization_policy=authorization_policy) + config = Configurator() + config.set_authentication_policy(authentication_policy) + config.set_authorization_policy(authorization_policy) .. note:: the ``authentication_policy`` and ``authorization_policy`` - arguments may also be passed to the Configurator as :term:`dotted - Python name` values, each representing the dotted name path to a - suitable implementation global defined at Python module scope. + arguments may also be passed to their respective methods mentioned above + as :term:`dotted Python name` values, each representing the dotted name + path to a suitable implementation global defined at Python module scope. The above configuration enables a policy which compares the value of an "auth ticket" cookie passed in the request's environment which contains a reference @@ -110,9 +110,9 @@ to a single :term:`principal` against the principals present in any :term:`view`. While it is possible to mix and match different authentication and -authorization policies, it is an error to pass an authentication -policy without the authorization policy or vice versa to a -:term:`Configurator` constructor. +authorization policies, it is an error to configure a Pyramid application +with an authentication policy but without the authorization policy or vice +versa. If you do this, you'll receive an error at application startup time. See also the :mod:`pyramid.authorization` and :mod:`pyramid.authentication` modules for alternate implementations @@ -188,13 +188,8 @@ In support of making it easier to configure applications which are the permission string to all view registrations which don't otherwise name a ``permission`` argument. -These APIs are in support of configuring a default permission for an -application: - -- The ``default_permission`` constructor argument to the - :mod:`~pyramid.config.Configurator` constructor. - -- The :meth:`pyramid.config.Configurator.set_default_permission` method. +The :meth:`pyramid.config.Configurator.set_default_permission` method +supports configuring a default permission for an application. When a default permission is registered: @@ -605,8 +600,8 @@ that implements the following interface: current user on subsequent requests. """ After you do so, you can pass an instance of such a class into the -:class:`~pyramid.config.Configurator` class at configuration -time as ``authentication_policy`` to use it. +:class:`~pyramid.config.Configurator.set_authentication_policy` method +configuration time to use it. .. index:: single: authorization policy (creating) @@ -616,18 +611,16 @@ time as ``authentication_policy`` to use it. Creating Your Own Authorization Policy -------------------------------------- -An authorization policy is a policy that allows or denies access after -a user has been authenticated. By default, :app:`Pyramid` will use -the :class:`pyramid.authorization.ACLAuthorizationPolicy` if an -authentication policy is activated and an authorization policy isn't -otherwise specified. +An authorization policy is a policy that allows or denies access after a user +has been authenticated. Most :app:`Pyramid` applications will use the +default :class:`pyramid.authorization.ACLAuthorizationPolicy`. -In some cases, it's useful to be able to use a different +However, in some cases, it's useful to be able to use a different authorization policy than the default -:class:`~pyramid.authorization.ACLAuthorizationPolicy`. For -example, it might be desirable to construct an alternate authorization -policy which allows the application to use an authorization mechanism -that does not involve :term:`ACL` objects. +:class:`~pyramid.authorization.ACLAuthorizationPolicy`. For example, it +might be desirable to construct an alternate authorization policy which +allows the application to use an authorization mechanism that does not +involve :term:`ACL` objects. :app:`Pyramid` ships with only a single default authorization policy, so you'll need to create your own if you'd like to use a @@ -655,5 +648,5 @@ following interface: used.""" After you do so, you can pass an instance of such a class into the -:class:`~pyramid.config.Configurator` class at configuration -time as ``authorization_policy`` to use it. +:class:`~pyramid.config.Configurator.set_authorization_policy` method at +configuration time to use it. diff --git a/docs/narr/traversal.rst b/docs/narr/traversal.rst index ef875c8f0..8c5d950c1 100644 --- a/docs/narr/traversal.rst +++ b/docs/narr/traversal.rst @@ -3,6 +3,13 @@ Traversal ========= +This chapter explains the technical details of how traversal works in +Pyramid. + +For a quick example, see :doc:`hellotraversal`. + +For more about *why* you might use traversal, see :doc:`muchadoabouttraversal`. + A :term:`traversal` uses the URL (Universal Resource Locator) to find a :term:`resource` located in a :term:`resource tree`, which is a set of nested dictionary-like objects. Traversal is done by using each segment diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst index 03000629c..763c0e131 100644 --- a/docs/narr/viewconfig.rst +++ b/docs/narr/viewconfig.rst @@ -280,8 +280,8 @@ configured view. *This is an advanced feature, not often used by "civilians"*. ``request_method`` - This value can be one of the strings ``GET``, ``POST``, ``PUT``, - ``DELETE``, or ``HEAD`` representing an HTTP ``REQUEST_METHOD``. A view + This value can be a string (typically ``"GET"``, ``"POST"``, ``"PUT"``, + ``"DELETE"``, or ``"HEAD"``) representing an HTTP ``REQUEST_METHOD``. A view declaration with this argument ensures that the view will only be called when the request's ``method`` attribute (aka the ``REQUEST_METHOD`` of the WSGI environment) string matches the supplied value. @@ -926,7 +926,7 @@ there's a ``should_cache`` GET or POST variable: return response Note that the ``http_cache`` machinery will overwrite or add to caching -headers you set within the view itself unless you use ``preserve_auto``. +headers you set within the view itself unless you use ``prevent_auto``. You can also turn of the effect of ``http_cache`` entirely for the duration of a Pyramid application lifetime. To do so, set the diff --git a/docs/narr/views.rst b/docs/narr/views.rst index a3fd61098..fa34cca61 100644 --- a/docs/narr/views.rst +++ b/docs/narr/views.rst @@ -233,7 +233,7 @@ provided within :mod:`pyramid.httpexceptions`. How Pyramid Uses HTTP Exceptions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -HTTP exceptions are meant to be used directly by application application +HTTP exceptions are meant to be used directly by application developers. However, Pyramid itself will raise two HTTP exceptions at various points during normal operations: :exc:`pyramid.httpexceptions.HTTPNotFound` and |