diff options
| -rw-r--r-- | docs/narr/events.rst | 2 | ||||
| -rw-r--r-- | docs/narr/templates.rst | 20 | ||||
| -rw-r--r-- | docs/narr/unittesting.rst | 8 | ||||
| -rw-r--r-- | docs/tutorials/cmf/actions.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/cmf/catalog.rst | 6 | ||||
| -rw-r--r-- | docs/tutorials/cmf/content.rst | 6 | ||||
| -rw-r--r-- | docs/tutorials/cmf/index.rst | 12 | ||||
| -rw-r--r-- | docs/tutorials/cmf/missing.rst | 10 | ||||
| -rw-r--r-- | docs/tutorials/cmf/skins.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/cmf/workflow.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/gae/index.rst | 23 | ||||
| -rw-r--r-- | docs/tutorials/modwsgi/index.rst | 21 | ||||
| -rw-r--r-- | docs/tutorials/wiki/authorization.rst | 3 | ||||
| -rw-r--r-- | docs/tutorials/zeo/index.rst | 18 | ||||
| -rw-r--r-- | docs/tutorials/zodbsessions/index.rst | 12 |
15 files changed, 70 insertions, 77 deletions
diff --git a/docs/narr/events.rst b/docs/narr/events.rst index 99ea600fa..91eb27616 100644 --- a/docs/narr/events.rst +++ b/docs/narr/events.rst @@ -33,7 +33,7 @@ when it's called. The mere existence of a subscriber function, however, is not sufficient to arrange for it to be called. To arrange for the subscriber to be called, you'll need to use the -:meth:`pyramid.configurator.Configurator.add_subscriber` method to +:meth:`pyramid.configuration.Configurator.add_subscriber` method to register the subscriber imperatively, or via a decorator, or you'll need to use ZCML for the same purpose: diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst index f3536363c..0650480af 100644 --- a/docs/narr/templates.rst +++ b/docs/narr/templates.rst @@ -51,16 +51,14 @@ within the body of a view callable like so: .. warning:: Earlier iterations of this documentation (pre-version-1.3) encouraged the application developer to use ZPT-specific APIs such as - :func:`pyramid.chameleon_zpt.render_template_to_response`, - :func:`pyramid.chameleon_zpt.render_template_to_iterable`, and - :func:`pyramid.chameleon_zpt.render_template` to render - templates directly. This style of rendering still works, but at - least for purposes of this documentation, those functions are - deprecated. Application developers are encouraged instead to use - the functions available in the :mod:`pyramid.renderers` module - to perform rendering tasks. This set of functions works to render - templates for all renderer extensions registered with - :mod:`pyramid`. + :func:`pyramid.chameleon_zpt.render_template_to_response` and + :func:`pyramid.chameleon_zpt.render_template` to render templates + directly. This style of rendering still works, but at least for + purposes of this documentation, those functions are deprecated. + Application developers are encouraged instead to use the functions + available in the :mod:`pyramid.renderers` module to perform + rendering tasks. This set of functions works to render templates + for all renderer extensions registered with :mod:`pyramid`. The ``sample_view`` :term:`view callable` above returns a :term:`response` object which contains the body of the @@ -116,7 +114,7 @@ function. Every view must return a :term:`response` object (except for views which use a :term:`renderer` named via view configuration, which we'll -see shortly). The :func:`pyramid.renders.render_to_response` +see shortly). The :func:`pyramid.renderers.render_to_response` function is a shortcut function that actually returns a response object. diff --git a/docs/narr/unittesting.rst b/docs/narr/unittesting.rst index d6f854187..85f74ec0a 100644 --- a/docs/narr/unittesting.rst +++ b/docs/narr/unittesting.rst @@ -226,14 +226,14 @@ used the testing API. def test_view_fn_not_submitted(self): from my.package import view_fn - renderer = self.config.testing_add_template('templates/show.pt') + renderer = self.config.testing_add_renderer('templates/show.pt') request = testing.DummyRequest() response = view_fn(request) renderer.assert_(say='Hello') def test_view_fn_submitted(self): from my.package import view_fn - renderer = self.config.testing_add_template( + renderer = self.config.testing_add_renderer( 'templates/submitted.pt') request = testing.DummyRequest() request.params['say'] = 'Yo' @@ -249,7 +249,7 @@ The first test method, ``test_view_fn_not_submitted`` tests the ``view_fn`` function in the case that no "form" values (represented by request.params) have been submitted. Its first line registers a "dummy template renderer" named ``templates/show.pt`` via the -:meth:`pyramid.configuration.Configurator.testing_add_template` +:meth:`pyramid.configuration.Configurator.testing_add_renderer` method; this method returns a :class:`pyramid.testing.DummyTemplateRenderer` instance which we hang on to for later. @@ -367,7 +367,7 @@ environment. str(len(body)))) Unless you cannot avoid it, you should prefer writing unit tests that -use the :class:`pyramid.configuration,Configurator` API to set up +use the :class:`pyramid.configuration.Configurator` API to set up the right "mock" registrations rather than creating an integration test. Unit tests will run faster (because they do less for each test) and the result of a unit test is usually easier to make assertions diff --git a/docs/tutorials/cmf/actions.rst b/docs/tutorials/cmf/actions.rst index e16e70c52..0de6d580d 100644 --- a/docs/tutorials/cmf/actions.rst +++ b/docs/tutorials/cmf/actions.rst @@ -8,7 +8,7 @@ In CMF, the "actions tool" along with "action providers" create an extensible mechanism to show links in the CMF management UI that invoke a particular behavior or which show a particular template. -:mod:`repoze.bfg` itself has no such concept, and no package provides +:mod:`pyramid` itself has no such concept, and no package provides a direct replacement. Actions are such a generic concept that it's simple to reimplement action-like navigation in a different way within any given application. For example, a module-scope global dictionary diff --git a/docs/tutorials/cmf/catalog.rst b/docs/tutorials/cmf/catalog.rst index f9e147473..11a9483a6 100644 --- a/docs/tutorials/cmf/catalog.rst +++ b/docs/tutorials/cmf/catalog.rst @@ -8,7 +8,7 @@ The main feature of the CMF catalog is that it filters search results from the Zope 2 "catalog" based on the requesting user's ability to view a particular cataloged object. -:mod:`repoze.bfg` itself has no cataloging facility, but an addon +:mod:`pyramid` itself has no cataloging facility, but an addon package named :term:`repoze.catalog` offers similar functionality. Creating an Allowed Index @@ -24,7 +24,7 @@ Creating The ``allowed`` Index Here's some code which creates an ``allowed`` index for use in a ``repoze.catalog`` catalog:: - from repoze.bfg.security import principals_allowed_by_permission + from pyramid.security import principals_allowed_by_permission from repoze.catalog.indexes.keyword import CatalogKeywordIndex from repoze.catalog.catalog import Catalog @@ -53,7 +53,7 @@ Using the ``allowed`` Index Here's how you might use the ``allowed`` index within a query:: - from repoze.bfg.security import effective_principals + from pyramid.security import effective_principals principals = effective_principals(request) catalog.searchResults(allowed={'operator':'or', 'query':principals}) diff --git a/docs/tutorials/cmf/content.rst b/docs/tutorials/cmf/content.rst index a8f5adace..a8b2b8124 100644 --- a/docs/tutorials/cmf/content.rst +++ b/docs/tutorials/cmf/content.rst @@ -10,7 +10,7 @@ code which generates an instance of that content. It is possible to construct and enumerate content types using APIs defined on the types tool. -:mod:`repoze.bfg` itself has no such concept, but an addon package named +:mod:`pyramid` itself has no such concept, but an addon package named :term:`repoze.lemonade` has a barebones replacement. Factory Type Information @@ -22,7 +22,7 @@ initial view name, a factory, and a number of security settings with a type name. Each type information object knows how to manufacture content objects that match its type. -:mod:`repoze.bfg` certainly enforces none of these concepts in any +:mod:`pyramid` certainly enforces none of these concepts in any particular way, but :term:`repoze.lemonade` does. ``repoze.lemonade`` Content @@ -51,7 +51,7 @@ of helper functions which allow you to: content-agnostic unit tests or if you need to get an enumerated subset of content type information to aid in UI generation. That said, this *is* a tutorial about how to - get CMF-like features in :mod:`repoze.bfg`, so we'll assume + get CMF-like features in :mod:`pyramid`, so we'll assume the pattern is useful to readers. See the `repoze.lemonade package diff --git a/docs/tutorials/cmf/index.rst b/docs/tutorials/cmf/index.rst index 77d2ce02c..65ad99551 100644 --- a/docs/tutorials/cmf/index.rst +++ b/docs/tutorials/cmf/index.rst @@ -1,21 +1,21 @@ -Converting an Existing Zope/CMF Application to :mod:`repoze.bfg` +Converting an Existing Zope/CMF Application to :mod:`pyramid` ================================================================ The Zope `Content Management Framework <http://www.zope.org/Products/CMF/>`_ (aka CMF) is a layer on top of :term:`Zope` 2 that provides facilities for creating content-driven websites. It's reasonably easy to convert a modern Zope/CMF -application to :mod:`repoze.bfg`. +application to :mod:`pyramid`. -The main difference between CMF and :mod:`repoze.bfg` is that -:mod:`repoze.bfg` does not advertise itself as a system into which you +The main difference between CMF and :mod:`pyramid` is that +:mod:`pyramid` does not advertise itself as a system into which you can plug arbitrary "packages" that extend a system-supplied management user interface. You *could* build a CMF-like layer on top of -:mod:`repoze.bfg` (as CMF is built on Zope) but none currently exists. +:mod:`pyramid` (as CMF is built on Zope) but none currently exists. For those sorts of high-extensibility, highly-regularized-UI systems, CMF is still the better choice. -:mod:`repoze.bfg` (and other more lightweight systems) is often a +:mod:`pyramid` (and other more lightweight systems) is often a better choice when you're building the a user interface from scratch, which often happens when the paradigms of some CMF-provided user interface don't match the requirements of an application very closely. diff --git a/docs/tutorials/cmf/missing.rst b/docs/tutorials/cmf/missing.rst index e4faa30f7..e919d2528 100644 --- a/docs/tutorials/cmf/missing.rst +++ b/docs/tutorials/cmf/missing.rst @@ -1,8 +1,8 @@ Missing Comparisons =================== -We currently don't have any comparative BFG-vs-CMF information about -the following concepts within this tutorial: +We currently don't have any comparative Pyramid-vs-CMF information +about the following concepts within this tutorial: - Templates @@ -16,7 +16,7 @@ the following concepts within this tutorial: - Dublincore -Please ask on the `repoze-dev maillist -<http://lists.repoze.org/listinfo/repoze-dev>`_ or on the `#repoze IRC -channel <http://irc.freenode.net#repoze>`_ about these topics. +Please ask on the `Pylons-discuss maillist +<http://groups.google.com/group/pylons-discuss>`_ or on the `#pylons IRC +channel <http://irc.freenode.net#pylons>`_ about these topics. diff --git a/docs/tutorials/cmf/skins.rst b/docs/tutorials/cmf/skins.rst index 5f5c2c447..a81d584f7 100644 --- a/docs/tutorials/cmf/skins.rst +++ b/docs/tutorials/cmf/skins.rst @@ -12,7 +12,7 @@ products often provide skin layers that are activated within a particular skin to provide the site with additional features. To override static resources using a "search path" much like a set of -skin layers, :mod:`repoze.bfg` provides the concept of +skin layers, :mod:`pyramid` provides the concept of :term:`resource` overrides. See :ref:`overriding_resources_section` for more information about resource overrides. diff --git a/docs/tutorials/cmf/workflow.rst b/docs/tutorials/cmf/workflow.rst index ff9527591..35cf552d2 100644 --- a/docs/tutorials/cmf/workflow.rst +++ b/docs/tutorials/cmf/workflow.rst @@ -7,7 +7,7 @@ Workflow In CMF, the "workflow tool" allows developers to design state machines which imply transition between content states. -:mod:`repoze.bfg` itself has no such concept, but the +:mod:`pyramid` itself has no such concept, but the :term:`repoze.workflow` package provides a simple state machine implementation that can act as a barebones workflow tool. See its documentation for more information. diff --git a/docs/tutorials/gae/index.rst b/docs/tutorials/gae/index.rst index 1d6a1bad0..328d5bf61 100644 --- a/docs/tutorials/gae/index.rst +++ b/docs/tutorials/gae/index.rst @@ -1,14 +1,14 @@ .. _appengine_tutorial: -Running :mod:`repoze.bfg` on Google's App Engine +Running :mod:`pyramid` on Google's App Engine ================================================ -As of :mod:`repoze.bfg` version 0.8, it is possible to run a -:mod:`repoze.bfg` application on Google's `App Engine -<http://code.google.com/appengine/>`_. Content from this tutorial was -contributed by YoungKing, based on the `"appengine-monkey" tutorial -for Pylons <http://code.google.com/p/appengine-monkey/wiki/Pylons>`_. -This tutorial is written in terms of using the command line on a UNIX +It is possible to run a :mod:`pyramid` application on Google's `App +Engine <http://code.google.com/appengine/>`_. Content from this +tutorial was contributed by YoungKing, based on the +`"appengine-monkey" tutorial for Pylons +<http://code.google.com/p/appengine-monkey/wiki/Pylons>`_. This +tutorial is written in terms of using the command line on a UNIX system; it should be possible to perform similar actions on a Windows system. @@ -43,19 +43,18 @@ system. ``bfgapp/app/`` which is the directory you will upload to appengine. -#. Install :mod:`repoze.bfg` into the virtualenv +#. Install :mod:`pyramid` into the virtualenv .. code-block:: text $ cd bfgapp/ - $ bin/easy_install -i http://dist.repoze.org/bfg/current/simple/ \ - repoze.bfg + $ bin/easy_install pyramid - This will install :mod:`repoze.bfg` in the environment. + This will install :mod:`pyramid` in the environment. #. Create your application - We'll use the standard way to create a :mod:`repoze.bfg` + We'll use the standard way to create a :mod:`pyramid` application, but we'll have to move some files around when we are done. The below commands assume your current working directory is the ``bfgapp`` virtualenv directory you created in the third step diff --git a/docs/tutorials/modwsgi/index.rst b/docs/tutorials/modwsgi/index.rst index ed9a7a90b..5572e300b 100644 --- a/docs/tutorials/modwsgi/index.rst +++ b/docs/tutorials/modwsgi/index.rst @@ -1,6 +1,6 @@ .. _modwsgi_tutorial: -Running a :mod:`repoze.bfg` Application under ``mod_wsgi`` +Running a :mod:`pyramid` Application under ``mod_wsgi`` ========================================================== :term:`mod_wsgi` is an Apache module developed by Graham Dumpleton. @@ -8,15 +8,15 @@ It allows :term:`WSGI` programs to be served using the Apache web server. This guide will outline broad steps that can be used to get a -:mod:`repoze.bfg` application running under Apache via ``mod_wsgi``. +:mod:`pyramid` application running under Apache via ``mod_wsgi``. This particular tutorial was developed under Apple's Mac OS X platform (Snow Leopard, on a 32-bit Mac), but the instructions should be largely the same for all systems, delta specific path information for commands and files. .. note:: Unfortunately these instructions almost certainly won't work - for deploying a :mod:`repoze.bfg` application on a Windows system - using ``mod_wsgi``. If you have experience with :mod:`repoze.bfg` + for deploying a :mod:`pyramid` application on a Windows system + using ``mod_wsgi``. If you have experience with :mod:`pyramid` and ``mod_wsgi`` on Windows systems, please help us document this experience by submitting documentation to the `mailing list <http://lists.repoze.org/listinfo/repoze-dev>`_. @@ -49,18 +49,17 @@ commands and files. $ cd modwsgi $ /usr/local/bin/virtualenv --no-site-packages env -#. Install :mod:`repoze.bfg` into the newly created virtualenv: +#. Install :mod:`pyramid` into the newly created virtualenv: .. code-block:: text $ cd ~/modwsgi/env - $ bin/easy_install -i http://dist.repoze.org/bfg/current/simple \ - repoze.bfg + $ bin/easy_install repoze.bfg -#. Create and install your :mod:`repoze.bfg` application. For the +#. Create and install your :mod:`pyramid` application. For the purposes of this tutorial, we'll just be using the ``bfg_starter`` application as a baseline application. Substitute your existing - :mod:`repoze.bfg` application as necessary if you already have + :mod:`pyramid` application as necessary if you already have one. .. code-block:: text @@ -75,7 +74,7 @@ commands and files. .. code-block:: python - from repoze.bfg.paster import get_app + from pyramid.paster import get_app application = get_app( '/Users/chrism/modwsgi/env/myapp/myapp.ini', 'main') @@ -123,7 +122,7 @@ commands and files. :term:`mod_wsgi` has many knobs and a great variety of deployment modes. This is just one representation of how you might use it to -serve up a :mod:`repoze.bfg` application. See the `mod_wsgi +serve up a :mod:`pyramid` application. See the `mod_wsgi configuration documentation <http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines>`_ for more in-depth configuration information. diff --git a/docs/tutorials/wiki/authorization.rst b/docs/tutorials/wiki/authorization.rst index 48908a97b..0d135f5e2 100644 --- a/docs/tutorials/wiki/authorization.rst +++ b/docs/tutorials/wiki/authorization.rst @@ -16,9 +16,6 @@ The source code for this tutorial stage can be browsed via <http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki/src/authorization/>`_. -The source code for this tutorial stage can be browsed at -`docs.repoze.org <http://docs.repoze.org/bfgwiki-1.3/authorization>`_. - Configuring a ``pyramid`` Authentication Policy -------------------------------------------------- diff --git a/docs/tutorials/zeo/index.rst b/docs/tutorials/zeo/index.rst index a84abeb36..1f6d1dac3 100644 --- a/docs/tutorials/zeo/index.rst +++ b/docs/tutorials/zeo/index.rst @@ -4,18 +4,18 @@ Using ZODB with ZEO =================== :term:`ZODB` is a Python object persistence mechanism. :term:`ZODB` -works well as a storage mechanism for :mod:`repoze.bfg` applications, +works well as a storage mechanism for :mod:`pyramid` applications, especially in applications that use :term:`traversal`. :term:`ZEO` is an extension to ZODB which allows more than one process to simultaneously communicate with a ZODB storage. Making a ZODB database accessible to more than one process means that you can debug -your application objects at the same time that a :mod:`repoze.bfg` +your application objects at the same time that a :mod:`pyramid` server that accesses the database is running, and will also allow your application to run under multiprocess configurations, such as those exposed by :term:`mod_wsgi`. -The easiest way to get started with ZODB in a :mod:`repoze.bfg` +The easiest way to get started with ZODB in a :mod:`pyramid` application is to use the ZODB ``bfg_zodb`` paster template. See :ref:`additional_paster_templates` for more information about using this template. However, the Paster template does not set up a @@ -25,7 +25,7 @@ scratch". Installing Dependencies ----------------------- -#. Edit your :mod:`repoze.bfg` application's ``setup.py`` file, adding +#. Edit your :mod:`pyramid` application's ``setup.py`` file, adding the following packages to the ``install_requires`` of the application: @@ -47,7 +47,7 @@ Installing Dependencies setup( # ... other elements left out for brevity install_requires=[ - 'repoze.bfg', + 'pyramid', 'repoze.folder', 'repoze.retry', 'repoze.tm2', @@ -143,7 +143,7 @@ Configuration </blobstorage> #. For the purposes of this tutorial we'll assume that you want your - :mod:`repoze.bfg` application's :term:`root` object to be a + :mod:`pyramid` application's :term:`root` object to be a "folderish" object. To achieve this, change your application's ``models.py`` file to look like the below: @@ -165,13 +165,13 @@ Configuration .. code-block:: python - from repoze.bfg.configuration import Configurator + from pyramid.configuration import Configurator from repoze.zodbconn.finder import PersistentApplicationFinder from myapp.models import appmaker import transaction def app(global_config, **settings): - """ This function returns a ``repoze.bfg`` WSGI + """ This function returns a ``pyramid`` WSGI application. It is usually called by the PasteDeploy framework during @@ -224,7 +224,7 @@ Running .. code-block:: text :linenos: - [chrism@snowpro sess]$ ../bin/paster --plugin=repoze.bfg bfgshell \ + [chrism@snowpro sess]$ ../bin/paster --plugin=pyramid bfgshell \ myapp.ini myapp Python 2.5.4 (r254:67916, Sep 4 2009, 02:12:16) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin diff --git a/docs/tutorials/zodbsessions/index.rst b/docs/tutorials/zodbsessions/index.rst index 7d94e2e08..c32b457d5 100644 --- a/docs/tutorials/zodbsessions/index.rst +++ b/docs/tutorials/zodbsessions/index.rst @@ -21,13 +21,13 @@ sessioning to your application. usage documentation <http://docs.repoze.org/session/usage.html>`_. If you don't want to use ZODB to do sessioning, you might choose to use a relational/filestorage sessioning system such as `Beaker - <http://pypi.python.org/pypi/Beaker>`_. :mod:`repoze.bfg` is fully + <http://pypi.python.org/pypi/Beaker>`_. :mod:`pyramid` is fully compatible with this system too. Installing Dependencies ----------------------- -#. Edit your :mod:`repoze.bfg` application's ``setup.py`` file, adding +#. Edit your :mod:`pyramid` application's ``setup.py`` file, adding the following packages to the ``install_requires`` of the application: @@ -45,7 +45,7 @@ Installing Dependencies setup( # ... other elements left out for brevity install_requires=[ - 'repoze.bfg', + 'pyramid', 'repoze.folder', 'repoze.retry', 'repoze.tm2', @@ -147,7 +147,7 @@ Configuration :linenos: from repoze.session.manager import SessionDataManager - from repoze.bfg.traversal import find_root + from pyramid.traversal import find_root def get_session(context, request): root = find_root(context) @@ -167,8 +167,8 @@ Configuration :linenos: from repoze.session.manager import SessionDataManager - from repoze.bfg.traversal import find_root - from repoze.bfg.chameleon_zpt import render_template_to_response + from pyramid.traversal import find_root + from pyramid.chameleon_zpt import render_template_to_response def my_view(context, request): session = get_session(context, request) |