From c9c3c487bcaedeca97bb6463a00188b0dc01203a Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Tue, 18 Jan 2011 12:25:56 -0500 Subject: - Most references to ZCML in narrative chapters have been removed or redirected to ``pyramid_zcml`` locations. --- docs/zcml/aclauthorizationpolicy.rst | 35 ---- docs/zcml/adapter.rst | 47 ----- docs/zcml/asset.rst | 65 ------- docs/zcml/authtktauthenticationpolicy.rst | 102 ---------- docs/zcml/configure.rst | 95 ---------- docs/zcml/default_permission.rst | 57 ------ docs/zcml/forbidden.rst | 78 -------- docs/zcml/include.rst | 71 ------- docs/zcml/localenegotiator.rst | 39 ---- docs/zcml/notfound.rst | 78 -------- docs/zcml/remoteuserauthenticationpolicy.rst | 51 ----- docs/zcml/renderer.rst | 51 ----- docs/zcml/repozewho1authenticationpolicy.rst | 53 ------ docs/zcml/route.rst | 223 ---------------------- docs/zcml/scan.rst | 34 ---- docs/zcml/static.rst | 89 --------- docs/zcml/subscriber.rst | 45 ----- docs/zcml/translationdir.rst | 64 ------- docs/zcml/utility.rst | 46 ----- docs/zcml/view.rst | 266 --------------------------- 20 files changed, 1589 deletions(-) delete mode 100644 docs/zcml/aclauthorizationpolicy.rst delete mode 100644 docs/zcml/adapter.rst delete mode 100644 docs/zcml/asset.rst delete mode 100644 docs/zcml/authtktauthenticationpolicy.rst delete mode 100644 docs/zcml/configure.rst delete mode 100644 docs/zcml/default_permission.rst delete mode 100644 docs/zcml/forbidden.rst delete mode 100644 docs/zcml/include.rst delete mode 100644 docs/zcml/localenegotiator.rst delete mode 100644 docs/zcml/notfound.rst delete mode 100644 docs/zcml/remoteuserauthenticationpolicy.rst delete mode 100644 docs/zcml/renderer.rst delete mode 100644 docs/zcml/repozewho1authenticationpolicy.rst delete mode 100644 docs/zcml/route.rst delete mode 100644 docs/zcml/scan.rst delete mode 100644 docs/zcml/static.rst delete mode 100644 docs/zcml/subscriber.rst delete mode 100644 docs/zcml/translationdir.rst delete mode 100644 docs/zcml/utility.rst delete mode 100644 docs/zcml/view.rst (limited to 'docs/zcml') diff --git a/docs/zcml/aclauthorizationpolicy.rst b/docs/zcml/aclauthorizationpolicy.rst deleted file mode 100644 index f09531415..000000000 --- a/docs/zcml/aclauthorizationpolicy.rst +++ /dev/null @@ -1,35 +0,0 @@ -.. _aclauthorizationpolicy_directive: - -``aclauthorizationpolicy`` --------------------------- - -When this directive is used, authorization information is obtained -from :term:`ACL` objects attached to :term:`resource` objects. - -Attributes -~~~~~~~~~~ - -None. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -You may create an instance of the -:class:`pyramid.authorization.ACLAuthorizationPolicy` and pass it -to the :class:`pyramid.config.Configurator` constructor as -the ``authorization_policy`` argument during initial application -configuration. - -See Also -~~~~~~~~ - -See also :ref:`authorization_policies_directives_section` and -:ref:`security_chapter`. diff --git a/docs/zcml/adapter.rst b/docs/zcml/adapter.rst deleted file mode 100644 index 83cce0c39..000000000 --- a/docs/zcml/adapter.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _adapter_directive: - -``adapter`` ------------ - -Register a :term:`Zope Component Architecture` "adapter". - -Attributes -~~~~~~~~~~ - -``factory`` - The adapter factory (often a class). - -``provides`` - The :term:`interface` that an adapter instance resulting from a - lookup will provide. - -``for`` - Interfaces or classes to be adapted, separated by spaces, - e.g. ``interfaces.IFoo interfaces.IBar``. - -``name`` - The adapter name. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -Use the ``registerAdapter`` method of the ``registry`` attribute of a -:term:`Configurator` instance during initial application setup. - -See Also -~~~~~~~~ - -None. - diff --git a/docs/zcml/asset.rst b/docs/zcml/asset.rst deleted file mode 100644 index af7a6db94..000000000 --- a/docs/zcml/asset.rst +++ /dev/null @@ -1,65 +0,0 @@ -.. _asset_directive: - -``asset`` ---------- - -The ``asset`` directive adds an asset override for a single -static file/directory asset. - -Attributes -~~~~~~~~~~ - -``to_override`` - A :term:`asset specification` specifying the asset to be - overridden. - -``override_with`` - A :term:`asset specification` specifying the asset which - is used as the override. - -Examples -~~~~~~~~ - -.. topic:: Overriding a Single Asset File - - .. code-block:: xml - :linenos: - - - -.. topic:: Overriding all Assets in a Package - - .. code-block:: xml - :linenos: - - - -.. topic:: Overriding all Assets in a Subdirectory of a Package - - .. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -The :meth:`pyramid.config.Configurator.override_asset` -method can be used instead of the ``resource`` ZCML directive. - -This directive can also be invoked as the ``resource`` ZCML directive for -backwards compatibility purposes. - -See Also -~~~~~~~~ - -See also :ref:`asset_zcml_directive`. diff --git a/docs/zcml/authtktauthenticationpolicy.rst b/docs/zcml/authtktauthenticationpolicy.rst deleted file mode 100644 index 25be4186c..000000000 --- a/docs/zcml/authtktauthenticationpolicy.rst +++ /dev/null @@ -1,102 +0,0 @@ -.. _authtktauthenticationpolicy_directive: - -``authtktauthenticationpolicy`` -------------------------------- - -When this directive is used, authentication information is obtained -from an :mod:`paste.auth.auth_tkt` cookie value, assumed to be set by -a custom login form. - -Attributes -~~~~~~~~~~ - -``secret`` - The ``secret`` is a string that will be used to sign the data - stored by the cookie. It is required and has no default. - -``callback`` - The ``callback`` is a Python dotted name to a function passed the - string representing the userid stored in the cookie and the - request as positional arguments. The callback is expected to - return None if the user represented by the string doesn't exist or - a sequence of group identifiers (possibly empty) if the user does - exist. If ``callback`` is None, the userid will be assumed to - exist with no groups. It defaults to ``None``. - -``cookie_name`` - The ``cookie_name`` is the name used for the cookie that contains - the user information. It defaults to ``auth_tkt``. - -``secure`` - ``secure`` is a boolean value. If it's set to "true", the cookie - will only be sent back by the browser over a secure (HTTPS) - connection. It defaults to "false". - -``include_ip`` - ``include_ip`` is a boolean value. If it's set to true, the - requesting IP address is made part of the authentication data in - the cookie; if the IP encoded in the cookie differs from the IP of - the requesting user agent, the cookie is considered invalid. It - defaults to "false". - -``timeout`` - ``timeout`` is an integer value. It represents the maximum age in - seconds which the auth_tkt ticket will be considered valid. If - ``timeout`` is specified, and ``reissue_time`` is also specified, - ``reissue_time`` must be a smaller value than ``timeout``. It - defaults to ``None``, meaning that the ticket will be considered - valid forever. - -``reissue_time`` - ``reissue_time`` is an integer value. If ``reissue_time`` is - specified, when we encounter a cookie that is older than the - reissue time (in seconds), but younger that the ``timeout``, a new - cookie will be issued. It defaults to ``None``, meaning that - authentication cookies are never reissued. A value of ``0`` means - reissue a cookie in the response to every request that requires - authentication. - -``max_age`` - ``max_age`` is the maximum age of the auth_tkt *cookie*, in - seconds. This differs from ``timeout`` inasmuch as ``timeout`` - represents the lifetime of the ticket contained in the cookie, - while this value represents the lifetime of the cookie itself. - When this value is set, the cookie's ``Max-Age`` and ``Expires`` - settings will be set, allowing the auth_tkt cookie to last between - browser sessions. It is typically nonsensical to set this to a - value that is lower than ``timeout`` or ``reissue_time``, although - it is not explicitly prevented. It defaults to ``None``, meaning - (on all major browser platforms) that auth_tkt cookies will last - for the lifetime of the user's browser session. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -You may create an instance of the -:class:`pyramid.authentication.AuthTktAuthenticationPolicy` and -pass it to the :class:`pyramid.config.Configurator` -constructor as the ``authentication_policy`` argument during initial -application configuration. - -See Also -~~~~~~~~ - -See also :ref:`authentication_policies_directives_section` and -:class:`pyramid.authentication.AuthTktAuthenticationPolicy`. diff --git a/docs/zcml/configure.rst b/docs/zcml/configure.rst deleted file mode 100644 index cab8ec204..000000000 --- a/docs/zcml/configure.rst +++ /dev/null @@ -1,95 +0,0 @@ -.. _configure_directive: - -``configure`` -------------- - -Because :term:`ZCML` is XML, and because XML requires a single root -tag for each document, every ZCML file used by :app:`Pyramid` must -contain a ``configure`` container directive, which acts as the root -XML tag. It is a "container" directive because its only job is to -contain other directives. - -Attributes -~~~~~~~~~~ - -``xmlns`` - The default XML namespace used for subdirectives. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - - - - - -.. _word_on_xml_namespaces: - -A Word On XML Namespaces -~~~~~~~~~~~~~~~~~~~~~~~~ - -Usually, the start tag of the ```` container tag has a -default *XML namespace* associated with it. This is usually -``http://pylonshq.com/pyramid``, named by the ``xmlns`` attribute of -the ``configure`` start tag. - -Using the ``http://pylonshq.com/pyramid`` namespace as the default XML -namespace isn't strictly necessary; you can use a different default -namespace as the default. However, if you do, the declaration tags -which are defined by :app:`Pyramid` such as the ``view`` declaration -tag will need to be defined in such a way that the XML parser that -:app:`Pyramid` uses knows which namespace the :mod:`pyramid` tags are -associated with. For example, the following files are all completely -equivalent: - -.. topic:: Use of A Non-Default XML Namespace - - .. code-block:: xml - :linenos: - - - - - - - - - -.. topic:: Use of A Per-Tag XML Namespace Without A Default XML Namespace - - .. code-block:: xml - :linenos: - - - - - - - - - -For more information about XML namespaces, see `this older, but simple -XML.com article `_. - -The conventions in this document assume that the default XML namespace -is ``http://pylonshq.com/pyramid``. - -Alternatives -~~~~~~~~~~~~ - -None. - -See Also -~~~~~~~~ - -See also :ref:`helloworld_declarative`. - diff --git a/docs/zcml/default_permission.rst b/docs/zcml/default_permission.rst deleted file mode 100644 index 54e720ea6..000000000 --- a/docs/zcml/default_permission.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. _default_permission_directive: - -``default_permission`` -------------------------------- - -Set the default permission to be used by all :term:`view -configuration` registrations. - -This directive accepts a single attribute ,``name``, which should be -used as the default permission string. An example of a permission -string: ``view``. Adding a default permission makes it unnecessary to -protect each view configuration with an explicit permission, unless -your application policy requires some exception for a particular view. - -If a default permission is *not* set, views represented by view -configuration registrations which do not explicitly declare a -permission will be executable by entirely anonymous users (any -authorization policy is ignored). - -There can be only one default permission active at a time within an -application, thus the ``default_permission`` directive can only be -used once in any particular set of ZCML. - -Attributes -~~~~~~~~~~ - -``name`` - Must be a string representing a :term:`permission`, - e.g. ``view``. - - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -Using the ``default_permission`` argument to the -:class:`pyramid.config.Configurator` constructor can be used -to achieve the same purpose. - -Using the -:meth:`pyramid.config.Configurator.set_default_permission` -method can be used to achieve the same purpose when using imperative -configuration. - -See Also -~~~~~~~~ - -See also :ref:`setting_a_default_permission`. diff --git a/docs/zcml/forbidden.rst b/docs/zcml/forbidden.rst deleted file mode 100644 index 70f65069e..000000000 --- a/docs/zcml/forbidden.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _forbidden_directive: - -``forbidden`` -------------- - -When :app:`Pyramid` can't authorize execution of a view based on -the :term:`authorization policy` in use, it invokes a :term:`forbidden -view`. The default forbidden response has a 401 status code and is -very plain, but it can be overridden as necessary using the -``forbidden`` ZCML directive. - -.. warning:: - - The ``forbidden`` ZCML directive is deprecated in :app:`Pyramid` - version 1.3. Instead, you should use the :ref:`view_directive` - directive with a ``context`` that names the - :exc:`pyramid.exceptions.Forbidden` class. See - :ref:`changing_the_forbidden_view` form more information. - -Attributes -~~~~~~~~~~ - -``view`` - The :term:`dotted Python name` to a :term:`view callable`. This - attribute is required unless a ``renderer`` attribute also exists. - If a ``renderer`` attribute exists on the directive, this attribute - defaults to a view that returns an empty dictionary (see - :ref:`views_which_use_a_renderer`). - -``attr`` - The attribute of the view callable to use if ``__call__`` is not - correct (has the same meaning as in the context of - :ref:`view_directive`; see the description of ``attr`` - there). - -``renderer`` - This is either a single string term (e.g. ``json``) or a string - implying a path or :term:`asset specification` - (e.g. ``templates/views.pt``) used when the view returns a - non-:term:`response` object. This attribute has the same meaning as - it would in the context of :ref:`view_directive`; see the - description of ``renderer`` there). - -``wrapper`` - The :term:`view name` (*not* an object dotted name) of another view - declared elsewhere in ZCML (or via the ``@view_config`` decorator) - which will receive the response body of this view as the - ``request.wrapped_body`` attribute of its own request, and the - response returned by this view as the ``request.wrapped_response`` - attribute of its own request. This attribute has the same meaning - as it would in the context of :ref:`view_directive`; see the - description of ``wrapper`` there). Note that the wrapper view - *should not* be protected by any permission; behavior is undefined - if it does. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -Use the :ref:`view_directive` directive with a ``context`` that names -the :exc:`pyramid.exceptions.Forbidden` class. - -Use the :meth:`pyramid.config.Configurator.add_view` method, -passing it a ``context`` which is the -:exc:`pyramid.exceptions.Forbidden` class. - -See Also -~~~~~~~~ - -See also :ref:`changing_the_forbidden_view`. diff --git a/docs/zcml/include.rst b/docs/zcml/include.rst deleted file mode 100644 index f55caa07c..000000000 --- a/docs/zcml/include.rst +++ /dev/null @@ -1,71 +0,0 @@ -.. _include_directive: - -``include`` ------------ - -The ``include`` directive includes configuration from an external ZCML -file. Use of the ``include`` tag allows a user to split configuration -across multiple ZCML files, and allows package distributors to provide -default ZCML configuration for specific purposes which can be -included by the integrator of the package as necessary. - -Attributes -~~~~~~~~~~ - -``package`` - A :term:`dotted Python name` which references a Python :term:`package`. - -``file`` - An absolute or relative filename which references a ZCML file. - -The ``package`` and ``file`` attributes can be used together or -separately as necessary. - -Examples -~~~~~~~~ - -.. topic:: Loading the File Named ``configure.zcml`` from a Package Implicitly - - .. code-block:: xml - :linenos: - - - -.. topic:: Loading the File Named ``other.zcml`` From the Current Package - - .. code-block:: xml - :linenos: - - - -.. topic:: Loading a File From a Subdirectory of the Current Package - - .. code-block:: xml - :linenos: - - - -.. topic:: Loading the File Named ``/absolute/path/other.zcml`` - - .. code-block:: xml - :linenos: - - - -.. topic:: Loading the File Named ``other.zcml`` From a Package Explicitly - - .. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -None. - -See Also -~~~~~~~~ - -See also :ref:`helloworld_declarative`. - diff --git a/docs/zcml/localenegotiator.rst b/docs/zcml/localenegotiator.rst deleted file mode 100644 index c90e649f6..000000000 --- a/docs/zcml/localenegotiator.rst +++ /dev/null @@ -1,39 +0,0 @@ -.. _localenegotiator_directive: - -``localenegotiator`` --------------------- - -Set the :term:`locale negotiator` for the current configurator to -support localization of text. - -Attributes -~~~~~~~~~~ - -``negotiator`` - - The :term:`dotted Python name` to a :term:`locale negotiator` - implementation. This attribute is required. If it begins with a - dot (``.``), the name will be considered relative to the directory - in which the ZCML file which contains this directive lives. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -Use :meth:`pyramid.config.Configurator.set_locale_negotiator` -method instance during initial application setup. - -See Also -~~~~~~~~ - -See also :ref:`activating_translation`. - diff --git a/docs/zcml/notfound.rst b/docs/zcml/notfound.rst deleted file mode 100644 index 739eccd49..000000000 --- a/docs/zcml/notfound.rst +++ /dev/null @@ -1,78 +0,0 @@ -.. _notfound_directive: - -``notfound`` ------------- - -.. warning:: - - The ``notfound`` ZCML directive is deprecated in :app:`Pyramid` - version 1.0. Instead, you should use the :ref:`view_directive` - directive with a ``context`` that names the - :exc:`pyramid.exceptions.NotFound` class. See - :ref:`changing_the_notfound_view` form more information. - -When :app:`Pyramid` can't map a URL to view code, it invokes a -:term:`not found view`. The default not found view is very plain, but -the view callable used can be configured via the ``notfound`` ZCML -tag. - -Attributes -~~~~~~~~~~ - -``view`` - The :term:`dotted Python name` to a :term:`view callable`. This - attribute is required unless a ``renderer`` attribute also exists. - If a ``renderer`` attribute exists on the directive, this attribute - defaults to a view that returns an empty dictionary (see - :ref:`views_which_use_a_renderer`). - -``attr`` - The attribute of the view callable to use if ``__call__`` is not - correct (has the same meaning as in the context of - :ref:`view_directive`; see the description of ``attr`` - there). - -``renderer`` - This is either a single string term (e.g. ``json``) or a string - implying a path or :term:`asset specification` - (e.g. ``templates/views.pt``) used when the view returns a - non-:term:`response` object. This attribute has the same meaning as - it would in the context of :ref:`view_directive`; see the - description of ``renderer`` there). - -``wrapper`` - The :term:`view name` (*not* an object dotted name) of another view - declared elsewhere in ZCML (or via the ``@view_config`` decorator) - which will receive the response body of this view as the - ``request.wrapped_body`` attribute of its own request, and the - response returned by this view as the ``request.wrapped_response`` - attribute of its own request. This attribute has the same meaning - as it would in the context of :ref:`view_directive`; see - the description of ``wrapper`` there). Note that the wrapper view - *should not* be protected by any permission; behavior is undefined - if it does. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -Use the :ref:`view_directive` directive with a ``context`` that names -the :exc:`pyramid.exceptions.NotFound` class. - -Use the :meth:`pyramid.config.Configurator.add_view` method, -passing it a ``context`` which is the -:exc:`pyramid.exceptions.NotFound` class. - -See Also -~~~~~~~~ - -See also :ref:`changing_the_notfound_view`. - diff --git a/docs/zcml/remoteuserauthenticationpolicy.rst b/docs/zcml/remoteuserauthenticationpolicy.rst deleted file mode 100644 index 56e73ee7a..000000000 --- a/docs/zcml/remoteuserauthenticationpolicy.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _remoteuserauthenticationpolicy_directive: - -``remoteuserauthenticationpolicy`` ----------------------------------- - -When this directive is used, authentication information is obtained -from a ``REMOTE_USER`` key in the WSGI environment, assumed to -be set by a WSGI server or an upstream middleware component. - -Attributes -~~~~~~~~~~ - -``environ_key`` - The ``environ_key`` is the name that will be used to obtain the - remote user value from the WSGI environment. It defaults to - ``REMOTE_USER``. - -``callback`` - The ``callback`` is a Python dotted name to a function passed the - string representing the remote user and the request as positional - arguments. The callback is expected to return None if the user - represented by the string doesn't exist or a sequence of group - identifiers (possibly empty) if the user does exist. If - ``callback`` is None, the userid will be assumed to exist with no - groups. It defaults to ``None``. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -You may create an instance of the -:class:`pyramid.authentication.RemoteUserAuthenticationPolicy` and -pass it to the :class:`pyramid.config.Configurator` -constructor as the ``authentication_policy`` argument during initial -application configuration. - -See Also -~~~~~~~~ - -See also :ref:`authentication_policies_directives_section` and -:class:`pyramid.authentication.RemoteUserAuthenticationPolicy`. diff --git a/docs/zcml/renderer.rst b/docs/zcml/renderer.rst deleted file mode 100644 index c7beead32..000000000 --- a/docs/zcml/renderer.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. _renderer_directive: - -``renderer`` ------------- - -The ``renderer`` ZCML directive can be used to override an existing -existing :term:`renderer` or to add a new renderer. - -Attributes -~~~~~~~~~~ - -``factory`` - A :term:`dotted Python name` referencing a callable object that - accepts a renderer name and returns a :term:`renderer` object. - -``name`` - The renderer name, which is a string. - -Examples -~~~~~~~~ - -.. topic:: Registering a Non-Template Renderer - - .. code-block:: xml - :linenos: - - - -.. topic:: Registering a Template Renderer - - .. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -The :meth:`pyramid.config.Configurator.add_renderer` method -is equivalent to the ``renderer`` ZCML directive. - -See Also -~~~~~~~~ - -See also :ref:`adding_and_overriding_renderers`. diff --git a/docs/zcml/repozewho1authenticationpolicy.rst b/docs/zcml/repozewho1authenticationpolicy.rst deleted file mode 100644 index 11907ce31..000000000 --- a/docs/zcml/repozewho1authenticationpolicy.rst +++ /dev/null @@ -1,53 +0,0 @@ -.. _repozewho1authenticationpolicy_directive: - -``repozewho1authenticationpolicy`` ----------------------------------- - -When this directive is used, authentication information is obtained -from a ``repoze.who.identity`` key in the WSGI environment, assumed to -be set by :term:`repoze.who` middleware. - -Attributes -~~~~~~~~~~ - -``identifier_name`` - The ``identifier_name`` controls the name used to look up the - :term:`repoze.who` "identifier" plugin within - ``request.environ['repoze.who.plugins']`` which is used by this - policy to "remember" and "forget" credentials. It defaults to - ``auth_tkt``. - -``callback`` - The ``callback`` is a Python dotted name to a function passed the - repoze.who identity and the request as positional arguments. The - callback is expected to return None if the user represented by the - identity doesn't exist or a sequence of group identifiers - (possibly empty) if the user does exist. If ``callback`` is None, - the userid will be assumed to exist with no groups. It defaults - to ``None``. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -You may create an instance of the -:class:`pyramid.authentication.RepozeWho1AuthenticationPolicy` and -pass it to the :class:`pyramid.config.Configurator` -constructor as the ``authentication_policy`` argument during initial -application configuration. - -See Also -~~~~~~~~ - -See also :ref:`authentication_policies_directives_section` and -:class:`pyramid.authentication.RepozeWho1AuthenticationPolicy`. diff --git a/docs/zcml/route.rst b/docs/zcml/route.rst deleted file mode 100644 index 0f94fa11b..000000000 --- a/docs/zcml/route.rst +++ /dev/null @@ -1,223 +0,0 @@ -.. _route_directive: - -``route`` ---------- - -The ``route`` directive adds a single :term:`route configuration` to -the :term:`application registry`. - -Attributes -~~~~~~~~~~ - -``pattern`` - The pattern of the route e.g. ``ideas/{idea}``. This attribute is - required. See :ref:`route_pattern_syntax` for information - about the syntax of route patterns. - - .. note:: For backwards compatibility purposes, the ``path`` - attribute can also be used instead of ``pattern``. - -``name`` - The name of the route, e.g. ``myroute``. This attribute is - required. It must be unique among all defined routes in a given - configuration. - -``factory`` - The :term:`dotted Python name` to a function that will generate a - :app:`Pyramid` context object when this route matches. - e.g. ``mypackage.resources.MyResource``. If this argument is not - specified, a default root factory will be used. - -``view`` - The :term:`dotted Python name` to a function that will be used as a - view callable when this route matches. - e.g. ``mypackage.views.my_view``. - -``xhr`` - This value should be either ``True`` or ``False``. If this value is - specified and is ``True``, the :term:`request` must possess an - ``HTTP_X_REQUESTED_WITH`` (aka ``X-Requested-With``) header for this - route to match. This is useful for detecting AJAX requests issued - from jQuery, Prototype and other Javascript libraries. If this - predicate returns false, route matching continues. - -``traverse`` - If you would like to cause the :term:`context` to be something other - than the :term:`root` object when this route matches, you can spell - a traversal pattern as the ``traverse`` argument. This traversal - pattern will be used as the traversal path: traversal will begin at - the root object implied by this route (either the global root, or - the object returned by the ``factory`` associated with this route). - - The syntax of the ``traverse`` argument is the same as it is for - ``pattern``. For example, if the ``pattern`` provided to the - ``route`` directive is ``articles/{article}/edit``, and the - ``traverse`` argument provided to the ``route`` directive is - ``/{article}``, when a request comes in that causes the route to - match in such a way that the ``article`` match value is '1' (when - the request URI is ``/articles/1/edit``), the traversal path will be - generated as ``/1``. This means that the root object's - ``__getitem__`` will be called with the name ``1`` during the - traversal phase. If the ``1`` object exists, it will become the - :term:`context` of the request. :ref:`traversal_chapter` has more - information about traversal. - - If the traversal path contains segment marker names which are not - present in the ``pattern`` argument, a runtime error will occur. - The ``traverse`` pattern should not contain segment markers that do - not exist in the ``pattern``. - - A similar combining of routing and traversal is available when a - route is matched which contains a ``*traverse`` remainder marker in - its ``pattern`` (see :ref:`using_traverse_in_a_route_pattern`). The - ``traverse`` argument to the ``route`` directive allows you to - associate route patterns with an arbitrary traversal path without - using a a ``*traverse`` remainder marker; instead you can use other - match information. - - Note that the ``traverse`` argument to the ``route`` directive is - ignored when attached to a route that has a ``*traverse`` remainder - marker in its pattern. - -``request_method`` - A string representing an HTTP method name, e.g. ``GET``, ``POST``, - ``HEAD``, ``DELETE``, ``PUT``. If this argument is not specified, - this route will match if the request has *any* request method. If - this predicate returns false, route matching continues. - -``path_info`` - The value of this attribute represents a regular expression pattern - that will be tested against the ``PATH_INFO`` WSGI environment - variable. If the regex matches, this predicate will be true. If - this predicate returns false, route matching continues. - -``request_param`` - This value can be any string. A view declaration with this - attribute ensures that the associated route will only match when the - request has a key in the ``request.params`` dictionary (an HTTP - ``GET`` or ``POST`` variable) that has a name which matches the - supplied value. If the value supplied to the attribute has a ``=`` - sign in it, e.g. ``request_params="foo=123"``, then the key - (``foo``) must both exist in the ``request.params`` dictionary, and - the value must match the right hand side of the expression (``123``) - for the route to "match" the current request. If this predicate - returns false, route matching continues. - -``header`` - The value of this attribute represents an HTTP header name or a - header name/value pair. If the value contains a ``:`` (colon), it - will be considered a name/value pair (e.g. ``User-Agent:Mozilla/.*`` - or ``Host:localhost``). The *value* of an attribute that represent - a name/value pair should be a regular expression. If the value does - not contain a colon, the entire value will be considered to be the - header name (e.g. ``If-Modified-Since``). If the value evaluates to - a header name only without a value, the header specified by the name - must be present in the request for this predicate to be true. If - the value evaluates to a header name/value pair, the header - specified by the name must be present in the request *and* the - regular expression specified as the value must match the header - value. Whether or not the value represents a header name or a - header name/value pair, the case of the header name is not - significant. If this predicate returns false, route matching - continues. - -``accept`` - The value of this attribute represents a match query for one or more - mimetypes in the ``Accept`` HTTP request header. If this value is - specified, it must be in one of the following forms: a mimetype - match token in the form ``text/plain``, a wildcard mimetype match - token in the form ``text/*`` or a match-all wildcard mimetype match - token in the form ``*/*``. If any of the forms matches the - ``Accept`` header of the request, this predicate will be true. If - this predicate returns false, route matching continues. - -``custom_predicates`` - - This value should be a sequence of references to custom predicate - callables. Use custom predicates when no set of predefined - predicates does what you need. Custom predicates can be combined - with predefined predicates as necessary. Each custom predicate - callable should accept two arguments: ``info`` and ``request`` - and should return either ``True`` or ``False`` after doing arbitrary - evaluation of the info and/or the request. If all custom and - non-custom predicate callables return ``True`` the associated route - will be considered viable for a given request. If any predicate - callable returns ``False``, route matching continues. Note that the - value ``info`` passed to a custom route predicate is a dictionary - containing matching information; see :ref:`custom_route_predicates` - for more information about ``info``. - -``view_context`` - The :term:`dotted Python name` to a class or an interface that the - :term:`context` of the view should match for the view named by the - route to be used. This attribute is only useful if the ``view`` - attribute is used. If this attribute is not specified, the default - (``None``) will be used. - - If the ``view`` attribute is not provided, this attribute has no - effect. - - This attribute can also be spelled as ``view_for`` or ``for_``; - these are valid older spellings. - -``view_permission`` - The permission name required to invoke the view associated with this - route. e.g. ``edit``. (see :ref:`using_security_with_urldispatch` - for more information about permissions). - - If the ``view`` attribute is not provided, this attribute has no - effect. - - This attribute can also be spelled as ``permission``. - -``view_renderer`` - This is either a single string term (e.g. ``json``) or a string - implying a path or :term:`asset specification` - (e.g. ``templates/views.pt``). If the renderer value is a single - term (does not contain a dot ``.``), the specified term will be used - to look up a renderer implementation, and that renderer - implementation will be used to construct a response from the view - return value. If the renderer term contains a dot (``.``), the - specified term will be treated as a path, and the filename extension - of the last element in the path will be used to look up the renderer - implementation, which will be passed the full path. The renderer - implementation will be used to construct a response from the view - return value. See :ref:`views_which_use_a_renderer` for more - information. - - If the ``view`` attribute is not provided, this attribute has no - effect. - - This attribute can also be spelled as ``renderer``. - -``view_attr`` - The view machinery defaults to using the ``__call__`` method of the - view callable (or the function itself, if the view callable is a - function) to obtain a response dictionary. The ``attr`` value allows - you to vary the method attribute used to obtain the response. For - example, if your view was a class, and the class has a method named - ``index`` and you wanted to use this method instead of the class' - ``__call__`` method to return the response, you'd say - ``attr="index"`` in the view configuration for the view. This is - most useful when the view definition is a class. - - If the ``view`` attribute is not provided, this attribute has no - effect. - -``use_global_views`` - When a request matches this route, and view lookup cannot find a view - which has a 'route_name' predicate argument that matches the route, - try to fall back to using a view that otherwise matches the context, - request, and view name (but does not match the route name predicate). - -Alternatives -~~~~~~~~~~~~ - -You can also add a :term:`route configuration` via: - -- Using the :meth:`pyramid.config.Configurator.add_route` method. - -See Also -~~~~~~~~ - -See also :ref:`urldispatch_chapter`. diff --git a/docs/zcml/scan.rst b/docs/zcml/scan.rst deleted file mode 100644 index df2cdd281..000000000 --- a/docs/zcml/scan.rst +++ /dev/null @@ -1,34 +0,0 @@ -.. _scan_directive: - -``scan`` --------- - -To make use of :term:`configuration decoration` decorators, you must -perform a :term:`scan`. A scan finds these decorators in code. The -``scan`` ZCML directive tells :app:`Pyramid` to begin such a scan. - -Attributes -~~~~~~~~~~ - -``package`` - The package to scan or the single dot (``.``), meaning the - "current" package (the package in which the ZCML file lives). - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -The :meth:`pyramid.config.Configurator.scan` method performs -the same job as the ``scan`` ZCML directive. - -See Also -~~~~~~~~ - -See also :ref:`mapping_views_using_a_decorator_section`. diff --git a/docs/zcml/static.rst b/docs/zcml/static.rst deleted file mode 100644 index 9538d18f0..000000000 --- a/docs/zcml/static.rst +++ /dev/null @@ -1,89 +0,0 @@ -.. _static_directive: - -``static`` ----------- - -Use of the ``static`` ZCML directive or allows you to serve static -resources (such as JavaScript and CSS files) within a -:app:`Pyramid` application. This mechanism makes static files -available at a name relative to the application root URL. - -Attributes -~~~~~~~~~~ - -``name`` - The (application-root-relative) URL prefix of the static directory. - For example, to serve static files from ``/static`` in most - applications, you would provide a ``name`` of ``static``. - -``path`` - A path to a directory on disk where the static files live. This - path may either be 1) absolute (e.g. ``/foo/bar/baz``) 2) - Python-package-relative (e.g. (``packagename:foo/bar/baz``) or 3) - relative to the package directory in which the ZCML file which - contains the directive (e.g. ``foo/bar/baz``). - -``cache_max_age`` - The number of seconds that the static resource can be cached, as - represented in the returned response's ``Expires`` and/or - ``Cache-Control`` headers, when any static file is served from this - directive. This defaults to 3600 (5 minutes). Optional. - -``permission`` - Used to specify the :term:`permission` required by a user to execute - this static view. This value defaults to the string - ``__no_permission_required__``. The ``__no_permission_required__`` - string is a special sentinel which indicates that, even if a - :term:`default permission` exists for the current application, the - static view should be renderered to completely anonymous users. - This default value is permissive because, in most web apps, static - resources seldom need protection from viewing. You should use this - option only if you register a static view which points at a - directory that contains resources which should be shown only if the - calling user has (according to the :term:`authorization policy`) a - particular permission. - -Examples -~~~~~~~~ - -.. topic:: Serving Static Files from an Absolute Path - - .. code-block:: xml - :linenos: - - - -.. topic:: Serving Static Files from a Package-Relative Path - - .. code-block:: xml - :linenos: - - - -.. topic:: Serving Static Files from a Current-Package-Relative Path - - .. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -:meth:`pyramid.config.Configurator.add_static_view` can also -be used to add a static view. - -See Also -~~~~~~~~ - -See also :ref:`static_resources_section` and -:ref:`generating_static_resource_urls`. diff --git a/docs/zcml/subscriber.rst b/docs/zcml/subscriber.rst deleted file mode 100644 index 25c4abf2e..000000000 --- a/docs/zcml/subscriber.rst +++ /dev/null @@ -1,45 +0,0 @@ -.. _subscriber_directive: - -``subscriber`` --------------- - -The ``subscriber`` ZCML directive configures an :term:`subscriber` -callable to listen for events broadcast by the :app:`Pyramid` web -framework. - -Attributes -~~~~~~~~~~ - -``for`` - The class or :term:`interface` that you are subscribing the listener for, - e.g. :class:`pyramid.events.NewRequest`. Registering a subscriber for a - specific class or interface limits the event types that the subscriber - will receive to those specified by the interface or class. Default: - ``zope.interface.Interface`` (implying *any* event type). - -``handler`` - A :term:`dotted Python name` which references an event handler - callable. The callable should accept a single argument: ``event``. - The return value of the callable is ignored. - -Examples -~~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -You can also register an event listener by using the -:meth:`pyramid.config.Configurator.add_subscriber` method. - -See Also -~~~~~~~~ - -See also :ref:`events_chapter`. diff --git a/docs/zcml/translationdir.rst b/docs/zcml/translationdir.rst deleted file mode 100644 index 5cf615d26..000000000 --- a/docs/zcml/translationdir.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _translationdir_directive: - -``translationdir`` ------------------- - -Add a :term:`gettext` :term:`translation directory` to the current -configuration for use in localization of text. - -Attributes -~~~~~~~~~~ - -``dir`` - The path to the translation directory. This path may either be 1) - absolute (e.g. ``/foo/bar/baz``) 2) Python-package-relative - (e.g. ``packagename:foo/bar/baz``) or 3) relative to the package - directory in which the ZCML file which contains the directive - (e.g. ``foo/bar/baz``). - -Example 1 -~~~~~~~~~ - -.. code-block:: xml - :linenos: - - - - - -Example 2 -~~~~~~~~~ - -.. code-block:: xml - :linenos: - - - - - -Example 3 -~~~~~~~~~ - -.. code-block:: xml - :linenos: - - - - - -Alternatives -~~~~~~~~~~~~ - -Use :meth:`pyramid.config.Configurator.add_translation_dirs` -method instance during initial application setup. - -See Also -~~~~~~~~ - -See also :ref:`activating_translation`. diff --git a/docs/zcml/utility.rst b/docs/zcml/utility.rst deleted file mode 100644 index 1341dfb83..000000000 --- a/docs/zcml/utility.rst +++ /dev/null @@ -1,46 +0,0 @@ -.. _utility_directive: - -``utility`` ------------ - -Register a :term:`Zope Component Architecture` "utility". - -Attributes -~~~~~~~~~~ - -``component`` - The utility component (cannot be specified if ``factory`` is - specified). - -``factory`` - A factory that creates a component (cannot be specified if - ``component`` is specified). - -``provides`` - The :term:`interface` that an utility instance resulting from a - lookup will provide. - -``name`` - The utility name. - -Example -~~~~~~~ - -.. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -Use the ``registerUtility`` method of the ``registry`` attribute of a -:term:`Configurator` instance during initial application setup. - -See Also -~~~~~~~~ - -None. diff --git a/docs/zcml/view.rst b/docs/zcml/view.rst deleted file mode 100644 index ba5c7bf23..000000000 --- a/docs/zcml/view.rst +++ /dev/null @@ -1,266 +0,0 @@ -.. _view_directive: - -``view`` --------- - -A ``view`` declaration directs :app:`Pyramid` to create a single -:term:`view configuration` registration in the current -:term:`application registry`. - -The ``view`` ZCML directive has many possible attributes. Some of the -attributes are descriptive or influence rendering. Other attributes -are :term:`predicate` attributes, meaning that they imply an -evaluation to true or false when view lookup is performed. - -*All* predicates named in a view configuration must evaluate to true -in order for the view callable it names to be considered "invokable" -for a given request. See :ref:`view_lookup` for a description of how -a view configuration matches (or doesn't match) during a request. - -The possible attributes of the ``view`` ZCML directive are described -below. They are divided into predicate and non-predicate categories. - -Attributes -~~~~~~~~~~ - -Non-Predicate Attributes -######################## - -``view`` - The :term:`dotted Python name` to a :term:`view callable`. This - attribute is required unless a ``renderer`` attribute also exists. - If a ``renderer`` attribute exists on the directive, this attribute - defaults to a view that returns an empty dictionary (see - :ref:`views_which_use_a_renderer`). - -``permission`` - The name of a *permission* that the user must possess in order to - call the view. See :ref:`view_security_section` for more - information about view security and permissions. - -``attr`` - The view machinery defaults to using the ``__call__`` method of the - view callable (or the function itself, if the view callable is a - function) to obtain a response dictionary. The ``attr`` value - allows you to vary the method attribute used to obtain the response. - For example, if your view was a class, and the class has a method - named ``index`` and you wanted to use this method instead of the - class' ``__call__`` method to return the response, you'd say - ``attr="index"`` in the view configuration for the view. This is - most useful when the view definition is a class. - -``renderer`` - This is either a single string term (e.g. ``json``) or a string - implying a path or :term:`asset specification` - (e.g. ``templates/views.pt``). If the renderer value is a single - term (does not contain a dot ``.``), the specified term will be used - to look up a renderer implementation, and that renderer - implementation will be used to construct a response from the view - return value. If the renderer term contains a dot (``.``), the - specified term will be treated as a path, and the filename extension - of the last element in the path will be used to look up the renderer - implementation, which will be passed the full path. The renderer - implementation will be used to construct a response from the view - return value. - - Note that if the view itself returns a response (see - :ref:`the_response`), the specified renderer implementation is never - called. - - When the renderer is a path, although a path is usually just a - simple relative pathname (e.g. ``templates/foo.pt``, implying that a - template named "foo.pt" is in the "templates" directory relative to - the directory in which the ZCML file is defined), a path can be - absolute, starting with a slash on UNIX or a drive letter prefix on - Windows. The path can alternately be a :term:`asset - specification` in the form - ``some.dotted.package_name:relative/path``, making it possible to - address template assets which live in a separate package. - - The ``renderer`` attribute is optional. If it is not defined, the - "null" renderer is assumed (no rendering is performed and the value - is passed back to the upstream BFG machinery unmolested). - -``wrapper`` - The :term:`view name` (*not* an object dotted name) of another view - declared elsewhere in ZCML (or via the ``@view_config`` decorator) - which will receive the response body of this view as the - ``request.wrapped_body`` attribute of its own request, and the - response returned by this view as the ``request.wrapped_response`` - attribute of its own request. Using a wrapper makes it possible to - "chain" views together to form a composite response. The response - of the outermost wrapper view will be returned to the user. The - wrapper view will be found as any view is found: see - :ref:`view_lookup`. The "best" wrapper view will be found based on - the lookup ordering: "under the hood" this wrapper view is looked up - via ``pyramid.view.render_view_to_response(context, request, - 'wrapper_viewname')``. The context and request of a wrapper view is - the same context and request of the inner view. If this attribute - is unspecified, no view wrapping is done. - -Predicate Attributes -#################### - -``name`` - The *view name*. Read the :ref:`traversal_chapter` to understand - the concept of a view name. - -``context`` - A :term:`dotted Python name` representing the Python class that the - :term:`context` must be an instance of, *or* the :term:`interface` - that the :term:`context` must provide in order for this view to be - found and called. This predicate is true when the :term:`context` - is an instance of the represented class or if the :term:`context` - provides the represented interface; it is otherwise false. An - alternate name for this attribute is ``for`` (this is an older - spelling). - -``route_name`` - *This attribute services an advanced feature that isn't often used - unless you want to perform traversal after a route has matched.* - This value must match the ``name`` of a ```` declaration (see - :ref:`urldispatch_chapter`) that must match before this view will be - called. Note that the ``route`` configuration referred to by - ``route_name`` usually has a ``*traverse`` token in the value of its - ``path``, representing a part of the path that will be used by - traversal against the result of the route's :term:`root factory`. - See :ref:`hybrid_chapter` for more information on using this - advanced feature. - -``request_type`` - This value should be a :term:`dotted Python name` string - representing the :term:`interface` that the :term:`request` must - have in order for this view to be found and called. The presence of - this attribute is largely for backwards compatibility with - older iterations of this framework. - -``request_method`` - This value can either be one of the strings 'GET', 'POST', 'PUT', - 'DELETE', or 'HEAD' representing an HTTP ``REQUEST_METHOD``. A view - declaration with this attribute ensures that the view will only be - called when the request's ``method`` (aka ``REQUEST_METHOD``) string - matches the supplied value. - -``request_param`` - This value can be any string. A view declaration with this - attribute ensures that the view will only be called when the request - has a key in the ``request.params`` dictionary (an HTTP ``GET`` or - ``POST`` variable) that has a name which matches the supplied value. - If the value supplied to the attribute has a ``=`` sign in it, - e.g. ``request_params="foo=123"``, then the key (``foo``) must both - exist in the ``request.params`` dictionary, and the value must match - the right hand side of the expression (``123``) for the view to - "match" the current request. - -``containment`` - This value should be a :term:`dotted Python name` string - representing the class that a graph traversal parent object of the - :term:`context` must be an instance of (or :term:`interface` that a - parent object must provide) in order for this view to be found and - called. Your resources must be "location-aware" to use this feature. - See :ref:`location_aware` for more information about - location-awareness. - -``xhr`` - This value should be either ``True`` or ``False``. If this value is - specified and is ``True``, the :term:`request` must possess an - ``HTTP_X_REQUESTED_WITH`` (aka ``X-Requested-With``) header that has - the value ``XMLHttpRequest`` for this view to be found and called. - This is useful for detecting AJAX requests issued from jQuery, - Prototype and other Javascript libraries. - -``accept`` - The value of this attribute represents a match query for one or more - mimetypes in the ``Accept`` HTTP request header. If this value is - specified, it must be in one of the following forms: a mimetype - match token in the form ``text/plain``, a wildcard mimetype match - token in the form ``text/*`` or a match-all wildcard mimetype match - token in the form ``*/*``. If any of the forms matches the - ``Accept`` header of the request, this predicate will be true. - -``header`` - The value of this attribute represents an HTTP header name or a - header name/value pair. If the value contains a ``:`` (colon), it - will be considered a name/value pair (e.g. ``User-Agent:Mozilla/.*`` - or ``Host:localhost``). The *value* of an attribute that represent - a name/value pair should be a regular expression. If the value does - not contain a colon, the entire value will be considered to be the - header name (e.g. ``If-Modified-Since``). If the value evaluates to - a header name only without a value, the header specified by the name - must be present in the request for this predicate to be true. If - the value evaluates to a header name/value pair, the header - specified by the name must be present in the request *and* the - regular expression specified as the value must match the header - value. Whether or not the value represents a header name or a - header name/value pair, the case of the header name is not - significant. - -``path_info`` - The value of this attribute represents a regular expression pattern - that will be tested against the ``PATH_INFO`` WSGI environment - variable. If the regex matches, this predicate will be true. - -``custom_predicates`` - This value should be a sequence of references to custom predicate - callables (e.g. ``dotted.name.one dotted.name.two``, if used in - ZCML; a :term:`dotted Python name` to each callable separated by a - space). Use custom predicates when no set of predefined predicates - do what you need. Custom predicates can be combined with predefined - predicates as necessary. Each custom predicate callable should - accept two arguments: ``context`` and ``request`` and should return - either ``True`` or ``False`` after doing arbitrary evaluation of the - context and/or the request. If all callables return ``True``, the - associated view callable will be considered viable for a given - request. - -``decorator`` - A :term:`dotted Python name` to a function that will be used to decorate - the registered :term:`view callable`. The decorator function will be - called with the view callable as a single argument. The view callable it - is passed will accept ``(context, request)``. The decorator must return a - replacement view callable which also accepts ``(context, request)``. - -``mapper`` - A :term:`dotted Python name` which refers to a :term:`view mapper`, or - ``None``. By default it is ``None``, which indicates that the view should - use the default view mapper. This plug-point is useful for Pyramid - extension developers, but it's not very useful for 'civilians' who are just - developing stock Pyramid applications. - -Examples -~~~~~~~~ - -.. topic:: Registering A Default View for a Class - - .. code-block:: xml - :linenos: - - - -.. topic:: Registering A View With a Predicate - - .. code-block:: xml - :linenos: - - - -Alternatives -~~~~~~~~~~~~ - -You can also add a :term:`view configuration` via: - -- Using the :class:`pyramid.view.view_config` class as a decorator. - -- Using the :meth:`pyramid.config.Configurator.add_view` method. - -See Also -~~~~~~~~ - -See also :ref:`views_chapter`. -- cgit v1.2.3