From c9c3c487bcaedeca97bb6463a00188b0dc01203a Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Tue, 18 Jan 2011 12:25:56 -0500 Subject: [PATCH] - Most references to ZCML in narrative chapters have been removed or redirected to ``pyramid_zcml`` locations. --- CHANGES.txt | 9 +- docs/authorintro.rst | 6 - docs/designdefense.rst | 33 +-- docs/glossary.rst | 81 +++--- docs/index.rst | 4 +- docs/latexindex.rst | 30 --- docs/narr/advconfig.rst | 7 +- docs/narr/events.rst | 3 - docs/narr/hooks.rst | 14 - docs/narr/i18n.rst | 5 - docs/narr/project.rst | 7 - docs/narr/renderers.rst | 4 - docs/narr/security.rst | 8 - docs/narr/testing.rst | 29 +- docs/narr/urldispatch.rst | 3 - docs/narr/viewconfig.rst | 8 - docs/narr/zca.rst | 45 +--- docs/tutorials/bfg/index.rst | 4 + docs/zcml.rst | 32 --- 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 ------------------- 39 files changed, 74 insertions(+), 1847 deletions(-) delete mode 100644 docs/zcml.rst 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 diff --git a/CHANGES.txt b/CHANGES.txt index d3f8269581..0cce2e28e5 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -26,8 +26,8 @@ Backwards Incompatibilities - The ``pyramid.includes`` subpackage has been removed. ZCML files which use include the package ``pyramid.includes`` (e.g. ````) now must include the ``pyramid_zcml`` - package instead (e.g. ``). + package="pyramid.includes"/>``) now must include the ``pyramid_zcml`` + package instead (e.g. ````). - The ``pyramid.view.action`` decorator has been removed from the Pyramid core. Handlers are now a feature of the ``pyramid_handlers`` package. It @@ -101,7 +101,10 @@ Documentation "Renderers" chapter in a section named "Overriding A Renderer at Runtime". - The "Declarative Configuration" narrative chapter has been removed (it was - moved to the ``pyramid_zcml`` pakcage). + moved to the ``pyramid_zcml`` package). + +- Most references to ZCML in narrative chapters have been removed or + redirected to ``pyramid_zcml`` locations. Deprecations ------------ diff --git a/docs/authorintro.rst b/docs/authorintro.rst index f5ac402b06..787b5d9feb 100644 --- a/docs/authorintro.rst +++ b/docs/authorintro.rst @@ -79,12 +79,6 @@ This book is divided into four major parts: :app:`Pyramid`. The API documentation is organized alphabetically by module name. -:ref:`zcml_reference` - - Comprehensive reference material for every :term:`ZCML directive` - provided by :app:`Pyramid`. The ZCML directive documentation is - organized alphabetically by directive name. - .. index:: single: repoze.zope2 single: Zope 3 diff --git a/docs/designdefense.rst b/docs/designdefense.rst index 594d42b9e7..1b77e61c9e 100644 --- a/docs/designdefense.rst +++ b/docs/designdefense.rst @@ -453,34 +453,11 @@ Pyramid "Encourages Use of ZCML" :term:`Zope Component Architecture` registry that :app:`Pyramid` uses for application configuration. Often people claim that Pyramid "needs ZCML". -Quick answer: it doesn't. At least not anymore. In :mod:`repoze.bfg` (the -predecessor to Pyramid) versions 1.0 and and 1.1, an application needed to -possess a ZCML file for it to begin executing successfully. However, -:mod:`repoze.bfg` 1.2 and greater (including :app:`Pyramid` 1.0) includes a -completely imperative mode for all configuration. You will be able to make -"single file" apps in this mode, which should help people who need to see -everything done completely imperatively. For example, the very most basic -:app:`Pyramid` "helloworld" program has become something like: - -.. code-block:: python - :linenos: - - from webob import Response - from paste.httpserver import serve - from pyramid.config import Configurator - - def hello_world(request): - return Response('Hello world!') - - if __name__ == '__main__': - config = Configurator() - config.add_view(hello_world) - app = config.make_wsgi_app() - serve(app) - -In this mode, no ZCML is required at all, nor any other sort of frameworky -frontend to application configuration. Hopefully this mode will allow people -who are used to doing everything imperatively feel more comfortable. +It doesn't. In :app:`Pyramid` 1.0, ZCML doesn't ship as part of the core; +instead it ships in the :term:`pyramid_zcml` add-on package, which is +completely optional. No ZCML is required at all to use :app:`Pyramid`, nor +any other sort of frameworky declarative frontend to application +configuration. Pyramid Uses ZCML; ZCML is XML and I Don't Like XML --------------------------------------------------- diff --git a/docs/glossary.rst b/docs/glossary.rst index 93d6253cc0..600092f873 100644 --- a/docs/glossary.rst +++ b/docs/glossary.rst @@ -89,9 +89,9 @@ Glossary dotted Python name A reference to a Python object by name using a string, in the form ``path.to.modulename:attributename``. Often used in Paste and - setuptools configurations. A variant is used in dotted names - within :term:`ZCML` attributes that name objects (such as the ZCML - "view" directive's "view" attribute): the colon (``:``) is not + setuptools configurations. A variant is used in dotted names within + configurator method arguments that name objects (such as the "add_view" + method's "view" and "context" attributes): the colon (``:``) is not used; in its place is a dot. view @@ -116,8 +116,8 @@ Glossary with configuration information. This configuration information helps map a given :term:`request` to a particular view callable and it can influence the response of a view callable. :app:`Pyramid` views can be - configured via :term:`imperative configuration`, :term:`ZCML` or by a - special ``@view_config`` decorator coupled with a :term:`scan`. See + configured via :term:`imperative configuration`, or by a special + ``@view_config`` decorator coupled with a :term:`scan`. See :ref:`view_config_chapter` for more information about view configuration. @@ -377,29 +377,10 @@ Glossary ultimately a :term:`view`). See also :term:`url dispatch`. route configuration - Route configuration is the act of using :term:`imperative - configuration` or a :term:`ZCML` ```` statement to - associate request parameters with a particular :term:`route` using - pattern matching and :term:`route predicate` statements. See - :ref:`urldispatch_chapter` for more information about route - configuration. - - ZCML - `Zope Configuration Markup Language - `_, an XML dialect - used by Zope and :app:`Pyramid` for configuration tasks. ZCML - is capable of performing different types of :term:`configuration - declaration`, but its primary purpose in :app:`Pyramid` is to - perform :term:`view configuration` and :term:`route configuration` - within the ``configure.zcml`` file in a :app:`Pyramid` - application. You can use ZCML as an alternative to - :term:`imperative configuration`. - - ZCML directive - A ZCML "tag" such as ```` or ````. - - ZCML declaration - The concrete use of a :term:`ZCML directive` within a ZCML file. + Route configuration is the act of associating request parameters with a + particular :term:`route` using pattern matching and :term:`route + predicate` statements. See :ref:`urldispatch_chapter` for more + information about route configuration. Zope Component Architecture The `Zope Component Architecture @@ -457,9 +438,9 @@ Glossary subscriber A callable which receives an :term:`event`. A callable becomes a - subscriber via :term:`imperative configuration` or the - ```` ZCML directive. See :ref:`events_chapter` for - more information. + subscriber via :term:`imperative configuration` or via + :term:`configuration decoration`. See :ref:`events_chapter` for more + information. request type An attribute of a :term:`request` that allows for specialization @@ -577,15 +558,13 @@ Glossary also `PEP 318 `_. configuration declaration - An individual method call made to an instance of a - :app:`Pyramid` :term:`Configurator` object which performs an - arbitrary action, such as registering a :term:`view configuration` - (via the ``view`` method of the configurator) or :term:`route - configuration` (via the ``route`` method of the configurator). A - set of configuration declarations is also usually implied via the - use of a :term:`ZCML declaration` within an application, or a set - of configuration declarations might be performed by a :term:`scan` - of code in a package. + An individual method call made to an instance of a :app:`Pyramid` + :term:`Configurator` object which performs an arbitrary action, such as + registering a :term:`view configuration` (via the ``add_view`` method of + the configurator) or :term:`route configuration` (via the ``add_route`` + method of the configurator). A set of configuration declarations is + also implied by the :term:`configuration decoration` detected by a + :term:`scan` of code in a package. configuration decoration Metadata implying one or more :term:`configuration declaration` @@ -609,8 +588,8 @@ Glossary declaration` required by your application. declarative configuration - The configuration mode in which you use :term:`ZCML` to make - a set of :term:`configuration declaration` statements. + The configuration mode in which you use :term:`ZCML` to make a set of + :term:`configuration declaration` statements. See :term:`pyramid_zcml`. Not Found view An :term:`exception view` invoked by :app:`Pyramid` when the @@ -862,3 +841,21 @@ Glossary ``request.matchdict`` when a :term:`URL dispatch` route has been matched. Its keys are names as identified within the route pattern; its values are the values matched by each pattern name. + + pyramid_zcml + An add-on package to :app:`Pyramid` which allows applications to be + configured via ZCML. It is available on :term:`PyPI`. If you use + ``pyramid_zcml``, you can use ZCML as an alternative to + :term:`imperative configuration`. + + ZCML + `Zope Configuration Markup Language + `_, an XML dialect + used by Zope and :term:`pyramid_zcml` for configuration tasks. + + ZCML directive + A ZCML "tag" such as ```` or ````. + + ZCML declaration + The concrete use of a :term:`ZCML directive` within a ZCML file. + diff --git a/docs/index.rst b/docs/index.rst index e0a0db2145..030b4dc1cd 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -85,14 +85,12 @@ applications to various platforms. Reference Material ================== -Reference material includes API documentation and documentation of -every :app:`Pyramid` :term:`ZCML directive`. +Reference material includes documentation for every :app:`Pyramid` API. .. toctree:: :maxdepth: 2 api - zcml Detailed Change History ======================= diff --git a/docs/latexindex.rst b/docs/latexindex.rst index a8232651be..2426ec4b07 100644 --- a/docs/latexindex.rst +++ b/docs/latexindex.rst @@ -97,7 +97,6 @@ API Reference api/renderers api/request api/response - api/router api/scripting api/security api/settings @@ -108,35 +107,6 @@ API Reference api/view api/wsgi -.. _zcml_reference: - -ZCML Directive Reference -@@@@@@@@@@@@@@@@@@@@@@@@ - -.. toctree:: - :maxdepth: 1 - - zcml/aclauthorizationpolicy - zcml/adapter - zcml/authtktauthenticationpolicy - zcml/asset - zcml/configure - zcml/default_permission - zcml/forbidden - zcml/include - zcml/localenegotiator - zcml/notfound - zcml/remoteuserauthenticationpolicy - zcml/renderer - zcml/repozewho1authenticationpolicy - zcml/route - zcml/scan - zcml/static - zcml/subscriber - zcml/translationdir - zcml/utility - zcml/view - .. backmatter:: Glossary and Index diff --git a/docs/narr/advconfig.rst b/docs/narr/advconfig.rst index eb9b70b121..8951166f58 100644 --- a/docs/narr/advconfig.rst +++ b/docs/narr/advconfig.rst @@ -115,11 +115,8 @@ allowing the circumstance to go unreported, by default Pyramid raises a running. Conflict detection happens for any kind of configuration: imperative -configuration, :term:`ZCML` configuration, or configuration that results from -the execution of a :term:`scan`. - -.. note:: If you use, ZCML, its conflict detection algorithm is described in - :ref:`zcml_conflict_detection`. +configuration or configuration that results from the execution of a +:term:`scan`. Manually Resolving Conflicts ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/narr/events.rst b/docs/narr/events.rst index 06b30883f4..6fc3d14243 100644 --- a/docs/narr/events.rst +++ b/docs/narr/events.rst @@ -82,9 +82,6 @@ function found via a :term:`scan`. decorated function for the decorator to have any effect. See :func:`pyramid.subscriber` for more information. -.. note:: You can also configure an event listener via ZCML. See - :ref:`zcml_event_listener`. - Either of the above registration examples implies that every time the :app:`Pyramid` framework emits an event object that supplies an :class:`pyramid.events.NewRequest` interface, the ``mysubscriber`` function diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst index 96515c1959..f75e0bcf50 100644 --- a/docs/narr/hooks.rst +++ b/docs/narr/hooks.rst @@ -70,9 +70,6 @@ Here's some sample code that implements a minimal NotFound view callable: :exc:`pyramid.exceptions.NotFound` exception instance. If available, the resource context will still be available as ``request.context``. -For information about how to configure a not found view via :term:`ZCML`, see -:ref:`notfound_zcml`. - .. index:: single: forbidden view @@ -138,9 +135,6 @@ Here's some sample code that implements a minimal forbidden view: an alternate forbidden view. For example, it would make sense to return a response with a ``403 Forbidden`` status code. -For information about how to configure a forbidden view via :term:`ZCML`, see -:ref:`forbidden_zcml`. - .. index:: single: request factory @@ -185,8 +179,6 @@ already constructed a :term:`configurator` it can also be registered via the config = Configurator() config.set_request_factory(MyRequest) -To use ZCML for the same purpose, see :ref:`changing_request_factory_zcml`. - .. index:: single: renderer globals @@ -242,9 +234,6 @@ already constructed a :term:`configurator` it can also be registered via the Another mechanism which allows event subscribers to add renderer global values exists in :ref:`beforerender_event`. -If you'd rather ZCML to register a renderer globals factory, see -:ref:`adding_renderer_globals_zcml`. - .. index:: single: before render event @@ -474,9 +463,6 @@ when the application :term:`root factory` returned an instance of the ``myapp.resources.MyRoot`` object. Otherwise it would use the default :app:`Pyramid` traverser to do traversal. -For information about how to configure an alternate traverser via -:term:`ZCML`, see :ref:`changing_traverser_zcml`. - .. index:: single: url generator diff --git a/docs/narr/i18n.rst b/docs/narr/i18n.rst index c2a5b8ce7f..e1b6acc7b6 100644 --- a/docs/narr/i18n.rst +++ b/docs/narr/i18n.rst @@ -890,9 +890,6 @@ will be merged into translations from a message catalog added earlier if both translation directories contain translations for the same locale and :term:`translation domain`. -.. note:: You can also add a translation directory via ZCML. See - :ref:`zcml_adding_a_translation_directory` - Setting the Locale ~~~~~~~~~~~~~~~~~~ @@ -1019,5 +1016,3 @@ For example: config = Configurator() config.set_locale_negotiator(my_locale_negotiator) -.. note:: You can also add a custom locale negotiator via ZCML. See - :ref:`zcml_adding_a_locale_negotiator` diff --git a/docs/narr/project.rst b/docs/narr/project.rst index a76a8ce511..24faad5da3 100644 --- a/docs/narr/project.rst +++ b/docs/narr/project.rst @@ -26,7 +26,6 @@ and so therefore they are often referred to as "paster templates". .. index:: single: paster templates single: pyramid_starter paster template - single: pyramid_starter_zcml paster template single: pyramid_zodb paster template single: pyramid_alchemy paster template single: pyramid_routesalchemy paster template @@ -45,8 +44,6 @@ each other on a number of axes: - the mechanism they use to map URLs to code (:term:`traversal` or :term:`URL dispatch`). -- the type of configuration used (:term:`ZCML` vs. imperative configuration). - - whether or not the ``pyramid_beaker`` library is relied upon as the sessioning implementation (as opposed to no sessioning or default sessioning). @@ -56,10 +53,6 @@ The included templates are these: ``pyramid_starter`` URL mapping via :term:`traversal` and no persistence mechanism. -``pyramid_starter_zcml`` - URL mapping via :term:`traversal` and no persistence mechanism, using - :term:`ZCML` (declarative configuration). - ``pyramid_zodb`` URL mapping via :term:`traversal` and persistence via :term:`ZODB`. diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst index 56d0a5199d..a80c5a9c22 100644 --- a/docs/narr/renderers.rst +++ b/docs/narr/renderers.rst @@ -400,10 +400,6 @@ factory. Renderers can be registered imperatively using the :meth:`pyramid.config.Configurator.add_renderer` API. -.. note:: The tasks described in this section can also be performed via - :term:`declarative configuration`. See - :ref:`zcml_adding_and_overriding_renderers`. - For example, to add a renderer which renders views which have a ``renderer`` attribute that is a path that ends in ``.jinja2``: diff --git a/docs/narr/security.rst b/docs/narr/security.rst index 62a4727bc9..ebaeb15265 100644 --- a/docs/narr/security.rst +++ b/docs/narr/security.rst @@ -106,9 +106,6 @@ See also the :mod:`pyramid.authorization` and :mod:`pyramid.authentication` modules for alternate implementations of authorization and authentication policies. -You can also enable a security policy declaratively via ZCML. See -:ref:`zcml_authorization_policy`. - .. index:: single: permissions single: protecting views @@ -154,9 +151,6 @@ may be performed via the ``@view_config`` decorator: """ Add blog entry code goes here """ pass -Or the same thing can be done using the ``permission`` attribute of the ZCML -:ref:`view_directive` directive. - As a result of any of these various view configuration statements, if an authorization policy is in place when the view callable is found during normal application operations, the requesting user will need to possess the @@ -189,8 +183,6 @@ application: :meth:`pyramid.config.Configurator.set_default_permission` method. -- The :ref:`default_permission_directive` ZCML directive. - When a default permission is registered: - if a view configuration names an explicit ``permission``, the default diff --git a/docs/narr/testing.rst b/docs/narr/testing.rst index 08c6e355b4..b9c62ea530 100644 --- a/docs/narr/testing.rst +++ b/docs/narr/testing.rst @@ -201,13 +201,11 @@ Without invoking any startup code or using the testing API, an attempt to run this view function in a unit test will result in an error. When a :app:`Pyramid` application starts normally, it will populate a :term:`application registry` using :term:`configuration declaration` calls -made against a :term:`Configurator` (sometimes deferring to the application's -``configure.zcml`` :term:`ZCML` file via ``load_zcml``). But if this -application registry is not created and populated (e.g. with an +made against a :term:`Configurator`. But if this application registry is not +created and populated (e.g. with an :meth:`pyramid.config.Configurator.add_view` :term:`configuration -declaration` or ``view`` declarations in :term:`ZCML`), like when you invoke -application code via a unit test, :app:`Pyramid` API functions will tend to -fail. +declaration`), like when you invoke application code via a unit test, +:app:`Pyramid` API functions will tend to fail. The testing API provided by :app:`Pyramid` allows you to simulate various application registry registrations for use under a unit testing framework @@ -310,12 +308,13 @@ implementations to give the code under test only enough context to run. some code *and* its integration with the rest of the :app:`Pyramid` framework. -In :app:`Pyramid` applications that use :term:`ZCML`, you can create an -integration test by *loading its ZCML* 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 making -sure that your tests have enough context to run properly, and it tests your -code's integration with the rest of :app:`Pyramid`. +In :app:`Pyramid` applications that are plugins to Pyramid, you can create an +integration test by including it's ``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 +making sure that your tests have enough context to run properly, and it tests +your code's integration with the rest of :app:`Pyramid`. Let's demonstrate this by showing an integration test for a view. The below test assumes that your application's package name is ``myapp``, and that @@ -333,12 +332,12 @@ after accessing some values that require a fully set up environment. class ViewIntegrationTests(unittest.TestCase): def setUp(self): """ This sets up the application registry with the - registrations your application declares in its configure.zcml - (including dependent registrations for pyramid itself). + registrations your application declares in its ``includeme`` + function. """ import myapp self.config = testing.setUp() - self.config.load_zcml('myapp:configure.zcml') + self.config.include('myapp') def tearDown(self): """ Clear out the application registry """ diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst index e64513a966..a9057003f7 100644 --- a/docs/narr/urldispatch.rst +++ b/docs/narr/urldispatch.rst @@ -1287,6 +1287,3 @@ References A tutorial showing how :term:`URL dispatch` can be used to create a :app:`Pyramid` application exists in :ref:`bfg_sql_wiki_tutorial`. -Route configuration may also be added to the system via :term:`ZCML` (see -:ref:`zcml_route_configuration`). - diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst index 9b2074a70e..3f2b1b179d 100644 --- a/docs/narr/viewconfig.rst +++ b/docs/narr/viewconfig.rst @@ -63,11 +63,6 @@ View configuration is performed in one of these ways: :meth:`pyramid.config.Configurator.add_route` method, passing a ``view`` argument specifying a view callable. -.. note:: You can also add view configuration by adding a ```` or - ```` declaration to :term:`ZCML` used by your application as per - :ref:`mapping_views_using_zcml_section`, :ref:`view_directive` or - :ref:`route_directive`. - .. note:: A package named ``pyramid_handlers`` (available from PyPI) provides an analogue of :term:`Pylons` -style "controllers", which are a special kind of view class which provides more automation when your application @@ -443,9 +438,6 @@ you *must* do use the ``scan`` method of a # pyramid.config.Configurator class config.scan() -.. note:: See :ref:`zcml_scanning` for information about how to invoke a scan - via ZCML (if you're not using imperative configuration). - Please see :ref:`decorations_and_code_scanning` for detailed information about what happens when code is scanned for configuration declarations resulting from use of decorators like :class:`pyramid.view.view_config`. diff --git a/docs/narr/zca.rst b/docs/narr/zca.rst index f330fd5516..394d02625e 100644 --- a/docs/narr/zca.rst +++ b/docs/narr/zca.rst @@ -158,9 +158,7 @@ Consider the following bit of idiomatic :app:`Pyramid` startup code: def app(global_settings, **settings): config = Configurator(settings=settings) - config.begin() - config.load_zcml('configure.zcml') - config.end() + config.include('some.other.package') return config.make_wsgi_app() When the ``app`` function above is run, a :term:`Configurator` is @@ -198,9 +196,7 @@ setup code. For example: def app(global_settings, **settings): config = Configurator(settings=settings) config.hook_zca() - config.begin() - config.load_zcml('configure.zcml') - config.end() + config.include('some.other.application') return config.make_wsgi_app() We've added a line to our original startup code, line number 6, which @@ -250,9 +246,7 @@ registry at startup time instead of constructing a new one: config = Configurator(registry=globalreg) config.setup_registry(settings=settings) config.hook_zca() - config.begin() - config.load_zcml('configure.zcml') - config.end() + config.include('some.other.application') return config.make_wsgi_app() Lines 5, 6, and 7 above are the interesting ones. Line 5 retrieves @@ -268,36 +262,3 @@ rather than creating a new application-specific registry; since by default the ZCA global API will use this registry, things will work as you might expect a Zope app to when you use the global ZCA API. -.. index:: - single: Zope ZCML directives - single: getGlobalSiteManager - single: getSiteManager - -Using Broken ZCML Directives ----------------------------- - -Some :term:`Zope` and third-party :term:`ZCML` directives use the -``zope.component.getGlobalSiteManager`` API to get "the registry" when -they should actually be calling ``zope.component.getSiteManager``. - -``zope.component.getSiteManager`` can be overridden by -:app:`Pyramid` via -:meth:`pyramid.config.Configurator.hook_zca`, while -``zope.component.getGlobalSiteManager`` cannot. Directives that use -``zope.component.getGlobalSiteManager`` are effectively broken; no -ZCML directive should be using this function to find a registry to -populate. - -You cannot use ZCML directives which use -``zope.component.getGlobalSiteManager`` within a :app:`Pyramid` -application without passing the ZCA global registry to the -:term:`Configurator` constructor at application startup, as per -:ref:`using_the_zca_global_registry`. - -One alternative exists: fix the ZCML directive to use -``getSiteManager`` rather than ``getGlobalSiteManager``. If a -directive disuses ``getGlobalSiteManager``, the ``hook_zca`` method of -using a component registry as documented in :ref:`hook_zca` will begin -to work, allowing you to make use of the ZCML directive without -also using the ZCA global registry. - diff --git a/docs/tutorials/bfg/index.rst b/docs/tutorials/bfg/index.rst index 3c0b3bf019..9f9a5238cd 100644 --- a/docs/tutorials/bfg/index.rst +++ b/docs/tutorials/bfg/index.rst @@ -176,6 +176,10 @@ Here's how to convert a :mod:`repoze.bfg` application to a + You will also need to add the ``pyramid_zcml`` package to your + ``setup.py`` ``install_requires`` list. In Pyramid, ZCML configuration + became an optional add-on supported by the ``pyramid_zcml`` package. + #. Retest your application using :app:`Pyramid`. This might be as easy as: diff --git a/docs/zcml.rst b/docs/zcml.rst deleted file mode 100644 index caced5c169..0000000000 --- a/docs/zcml.rst +++ /dev/null @@ -1,32 +0,0 @@ -.. _zcml_directives: - -ZCML Directives -=============== - -Comprehensive reference material for every ZCML directive provided by -:app:`Pyramid` is available within this chapter. The ZCML directive -documentation is organized alphabetically by directive name. - -.. toctree:: - :maxdepth: 1 - - zcml/aclauthorizationpolicy - zcml/adapter - zcml/authtktauthenticationpolicy - zcml/asset - zcml/configure - zcml/default_permission - zcml/forbidden - zcml/include - zcml/localenegotiator - zcml/notfound - zcml/remoteuserauthenticationpolicy - zcml/renderer - zcml/repozewho1authenticationpolicy - zcml/route - zcml/scan - zcml/static - zcml/subscriber - zcml/translationdir - zcml/utility - zcml/view diff --git a/docs/zcml/aclauthorizationpolicy.rst b/docs/zcml/aclauthorizationpolicy.rst deleted file mode 100644 index f09531415d..0000000000 --- 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 83cce0c391..0000000000 --- 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 af7a6db944..0000000000 --- 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 25be4186c3..0000000000 --- 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 cab8ec2047..0000000000 --- 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 54e720ea6c..0000000000 --- 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 70f65069e2..0000000000 --- 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 f55caa07c2..0000000000 --- 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 c90e649f62..0000000000 --- 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 739eccd496..0000000000 --- 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 56e73ee7a6..0000000000 --- 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 c7beead323..0000000000 --- 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 11907ce31b..0000000000 --- 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 0f94fa11b9..0000000000 --- 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 df2cdd2816..0000000000 --- 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 9538d18f0e..0000000000 --- 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 25c4abf2e2..0000000000 --- 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 5cf615d269..0000000000 --- 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 1341dfb83e..0000000000 --- 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 ba5c7bf23d..0000000000 --- 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`.