diff options
| -rw-r--r-- | CHANGES.txt | 8 | ||||
| -rw-r--r-- | TODO.txt | 7 | ||||
| -rw-r--r-- | docs/designdefense.rst | 164 | ||||
| -rw-r--r-- | docs/narr/declarative.rst | 2 | ||||
| -rw-r--r-- | docs/narr/events.rst | 41 | ||||
| -rw-r--r-- | docs/narr/hooks.rst | 45 | ||||
| -rw-r--r-- | docs/narr/router.rst | 19 | ||||
| -rw-r--r-- | docs/narr/startup.rst | 5 | ||||
| -rw-r--r-- | docs/tutorials/wiki/installation.rst | 4 | ||||
| -rw-r--r-- | docs/tutorials/wiki2/definingviews.rst | 2 | ||||
| -rw-r--r-- | docs/tutorials/wiki2/installation.rst | 4 | ||||
| -rw-r--r-- | docs/zcml/subscriber.rst | 13 | ||||
| -rw-r--r-- | pyramid/configuration.py | 2 | ||||
| -rw-r--r-- | pyramid/events.py | 9 | ||||
| -rw-r--r-- | pyramid/request.py | 2 | ||||
| -rw-r--r-- | pyramid/url.py | 8 |
16 files changed, 168 insertions, 167 deletions
diff --git a/CHANGES.txt b/CHANGES.txt index f9dcee32c..02f502711 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,6 +1,14 @@ Next release ============ +Documentation +------------- + +- All references to events by interface + (e.g. ``pyramid.interfaces.INewRequest``) have been changed to reference + their concrete classes (e.g. ``pyramid.events.NewRequest``) in + documentation about making subscriptions. + 1.0a1 (2010-11-05) ================== @@ -46,8 +46,6 @@ - Ability to use configurator as a context manager. -- Switch tutorials and templates to non-ZCML. - - Provide a response_cookies attribute on the request for rendered responses that can be used as input to response.set_cookie. @@ -92,3 +90,8 @@ - repoze.bfg.viewgroup in CMF tutorial - translationdir ZCML directive use of ``path_spec`` should maybe die. + +- Make settings an attribute of.. registry? request? Ugh. + +- Option for route_url to omit the host and port (perhaps a different + function named ``route_path``). diff --git a/docs/designdefense.rst b/docs/designdefense.rst index afeaba70c..92358ef0c 100644 --- a/docs/designdefense.rst +++ b/docs/designdefense.rst @@ -426,31 +426,27 @@ decision to use the ZCA registry: Conclusion ++++++++++ -If you only *develop applications* using :mod:`pyramid`, there's -not much to complain about here. You just should never need to -understand the ZCA registry or even know about its presence: use -documented :mod:`pyramid` APIs instead. However, you may be an -application developer who doesn't read API documentation because it's -unmanly. Instead you read the raw source code, and because you haven't -read the documentation, you don't know what functions, classes, and -methods even *form* the :mod:`pyramid` API. As a result, you've -now written code that uses internals and you've pained yourself into a -conceptual corner as a result of needing to wrestle with some -ZCA-using implementation detail. If this is you, it's extremely hard -to have a lot of sympathy for you. You'll either need to get familiar -with how we're using the ZCA registry or you'll need to use only the -documented APIs; that's why we document them as APIs. - -If you *extend* or *develop* :mod:`pyramid` (create new ZCML -directives, use some of the more obscure "ZCML hooks" as described in -:ref:`hooks_chapter`, or work on the :mod:`pyramid` core code), you -will be faced with needing to understand at least some ZCA concepts. -The ZCA registry API is quirky: we've tried to make it at least -slightly nicer by disusing it for common registrations and lookups -such as unnamed utilities. Some places it's used unabashedly, and -will be forever. We know it's quirky, but it's also useful and -fundamentally understandable if you take the time to do some reading -about it. +If you only *develop applications* using :mod:`pyramid`, there's not much to +complain about here. You just should never need to understand the ZCA +registry or even know about its presence: use documented :mod:`pyramid` APIs +instead. However, you may be an application developer who doesn't read API +documentation because it's unmanly. Instead you read the raw source code, and +because you haven't read the documentation, you don't know what functions, +classes, and methods even *form* the :mod:`pyramid` API. As a result, you've +now written code that uses internals and you've painted yourself into a +conceptual corner as a result of needing to wrestle with some ZCA-using +implementation detail. If this is you, it's extremely hard to have a lot of +sympathy for you. You'll either need to get familiar with how we're using +the ZCA registry or you'll need to use only the documented APIs; that's why +we document them as APIs. + +If you *extend* or *develop* :mod:`pyramid` (create new ZCML directives, use +some of the more obscure "ZCML hooks" as described in :ref:`hooks_chapter`, +or work on the :mod:`pyramid` core code), you will be faced with needing to +understand at least some ZCA concepts. In some places it's used unabashedly, +and will be forever. We know it's quirky, but it's also useful and +fundamentally understandable if you take the time to do some reading about +it. Pyramid Uses Interfaces Too Liberally ------------------------------------- @@ -700,21 +696,20 @@ the code that calls into the database lives somewhere in the ZODB object graph (or at least is a :term:`view` related to a node in the object graph), and traversal is required to reach this code. -I'll argue that URL dispatch is ultimately useful, even if you want to -use traversal as well. You can actually *combine* URL dispatch and -traversal in :mod:`pyramid` (see :ref:`hybrid_chapter`). One -example of such a usage: if you want to emulate something like Zope -2's "Zope Management Interface" UI on top of your object graph (or any -administrative interface), you can register a route like ``<route -name="manage" path="manage/*traverse"/>`` and then associate -"management" views in your code by using the ``route_name`` argument -to a ``view`` configuration, e.g. ``<view view=".some.callable" -context=".some.Model" route_name="manage"/>``. If you wire things up -this way someone then walks up to for example, ``/manage/ob1/ob2``, -they might be presented with a management interface, but walking up to -``/ob1/ob2`` would present them with the default object view. There -are other tricks you can pull in these hybrid configurations if you're -clever (and maybe masochistic) too. +I'll argue that URL dispatch is ultimately useful, even if you want to use +traversal as well. You can actually *combine* URL dispatch and traversal in +:mod:`pyramid` (see :ref:`hybrid_chapter`). One example of such a usage: if +you want to emulate something like Zope 2's "Zope Management Interface" UI on +top of your object graph (or any administrative interface), you can register +a route like ``<route name="manage" pattern="manage/*traverse"/>`` and then +associate "management" views in your code by using the ``route_name`` +argument to a ``view`` configuration, e.g. ``<view view=".some.callable" +context=".some.Model" route_name="manage"/>``. If you wire things up this +way someone then walks up to for example, ``/manage/ob1/ob2``, they might be +presented with a management interface, but walking up to ``/ob1/ob2`` would +present them with the default object view. There are other tricks you can +pull in these hybrid configurations if you're clever (and maybe masochistic) +too. Also, if you are a URL dispatch hater, if you should ever be asked to write an application that must use some legacy relational database @@ -734,13 +729,13 @@ just like you do in :term:`Zope`. Pyramid Views Do Not Accept Arbitrary Keyword Arguments ------------------------------------------------------- -Many web frameworks (Zope, TurboGears, Pylons, Django) allow for their -variant of a :term:`view callable` to accept arbitrary keyword or -positional arguments, which are "filled in" using values present in -the ``request.POST`` or ``request.GET`` dictionaries or by values -present in the "route match dictionary". For example, a Django view -will accept positional arguments which match information in an -associated "urlconf" such as ``r'^polls/(?P<poll_id>\d+)/$``: +Many web frameworks (Zope, TurboGears, Pylons 1.X, Django) allow for their +variant of a :term:`view callable` to accept arbitrary keyword or positional +arguments, which are "filled in" using values present in the ``request.POST`` +or ``request.GET`` dictionaries or by values present in the "route match +dictionary". For example, a Django view will accept positional arguments +which match information in an associated "urlconf" such as +``r'^polls/(?P<poll_id>\d+)/$``: .. code-block:: python :linenos: @@ -766,7 +761,7 @@ callable, the Zope request object's GET and POST namespaces are searched for keys which match the names of the positional and keyword arguments in the request, and the method is called (if possible) with its argument list filled with values mentioned therein. TurboGears -and Pylons operate similarly. +and Pylons 1.X operate similarly. :mod:`pyramid` has neither of these features. :mod:`pyramid` view callables always accept only ``context`` and ``request`` (or just @@ -835,7 +830,7 @@ written. If you don't like this, it doesn't mean you can't use :mod:`pyramid`. Just ignore this feature and avoid configuring an authorization or authentication policy and using ACLs. You can build -"Pylons-style" applications using :mod:`pyramid` that use their own +"Pylons-1.X-style" applications using :mod:`pyramid` that use their own security model via decorators or plain-old-imperative logic in view code. @@ -864,14 +859,13 @@ pyramid/ (except for ``pyramd/tests and pyramid/paster_templates``) 539K -The actual :mod:`pyramid` runtime code is about 10% of the total size -of the tarball omitting docs, helper templates used for package -generation, and test code. Of the approximately 19K lines of Python -code in the package, the code that actually has a chance of executing -during normal operation, excluding tests and paster template Python -files, accounts for approximately 5K lines of Python code. This is -comparable to Pylons, which ships with a little over 2K lines of -Python code, excluding tests. +The actual :mod:`pyramid` runtime code is about 10% of the total size of the +tarball omitting docs, helper templates used for package generation, and test +code. Of the approximately 19K lines of Python code in the package, the code +that actually has a chance of executing during normal operation, excluding +tests and paster template Python files, accounts for approximately 5K lines +of Python code. This is comparable to Pylons 1.X, which ships with a little +over 2K lines of Python code, excluding tests. Pyramid Has Too Many Dependencies --------------------------------- @@ -903,7 +897,7 @@ distribution dependencies. The number of dependencies required by :mod:`pyramid` is many times fewer than Grok (or Zope itself, upon which Grok is based). :mod:`pyramid` has a number of package distribution dependencies comparable to similarly-targeted frameworks -such as Pylons. +such as Pylons 1.X. We try not to reinvent too many wheels (at least the ones that don't need reinventing), and this comes at the cost of some number of @@ -1027,7 +1021,7 @@ possible by the use of the :term:`Zope Component Architecture` and fundamental application behavior to be overriden or extended. - The original developer may optionally choose to anticipate an - application-specific set of plugpoints, which will may be hooked by + application-specific set of plugpoints, which may be hooked by a deployer. If he chooses to use the facilities provided by the ZCA, the original developer does not need to think terribly hard about the mechanics of introducing such a plugpoint. @@ -1150,12 +1144,12 @@ access. I like this, because it means: #) When I use the security proxy machinery, I can have a view that conditionally displays certain HTML elements (like form fields) or - prevents certain attributes from being modified depending on the - depending on the permissions that the accessing user possesses with - respect to a context object. + prevents certain attributes from being modified depending on the the + permissions that the accessing user possesses with respect to a context + object. #) I want to also expose my model via a REST API using Twisted Web. If - If Pyramid performed authorization based on attribute access via Zope3's + Pyramid performed authorization based on attribute access via Zope3's security proies, I could enforce my authorization policy in both :mod:`pyramid` and in the Twisted-based system the same way. @@ -1371,29 +1365,27 @@ yourself in as an application developer: you probably didn't even know you signed up for the job, because the documentation offered by decorator-based microframeworks don't warn you about it. -Python application programmers do not control the module scope -codepath. Anyone who tries to sell you on the idea that they do is -simply mistaken. Test runners that you may want to use to run your -code's tests often perform imports of arbitrary code in strange orders -that manifest bugs like the one demonstrated above. API documentation -generation tools do the same. Some (mutant) people even think it's -safe to use the Python ``reload`` command or delete objects from -``sys.modules``, each of which has hilarious effects when used against -code that has import- time side effects. When Python programmers +Python application programmers do not control the module scope codepath. +Anyone who tries to sell you on the idea that they do is simply mistaken. +Test runners that you may want to use to run your code's tests often perform +imports of arbitrary code in strange orders that manifest bugs like the one +demonstrated above. API documentation generation tools do the same. Some +(mutant) people even think it's safe to use the Python ``reload`` command or +delete objects from ``sys.modules``, each of which has hilarious effects when +used against code that has import-time side effects. When Python programmers assume they can use the module-scope codepath to run arbitrary code -(especially code which populates an external registry), and this -assumption is challenged by reality, the application developer is -often required to undergo a painful, meticulous debugging process to -find the root cause of an inevitably obscure symptom. The solution is -often to rearrange application import ordering or move an import -statement from module-scope into a function body. The rationale for -doing so can never be expressed adequnately in the checkin message -which accompanies the fix or documented succinctly enough for the -benefit of the rest of the development team so that the problem never -happens again. It will happen again next month too, especially if you -are working on a project with other people who haven't yet -internalized the lessons you learned while you stepped through -module-scope code using ``pdb``. +(especially code which populates an external registry), and this assumption +is challenged by reality, the application developer is often required to +undergo a painful, meticulous debugging process to find the root cause of an +inevitably obscure symptom. The solution is often to rearrange application +import ordering or move an import statement from module-scope into a function +body. The rationale for doing so can never be expressed adequnately in the +checkin message which accompanies the fix or documented succinctly enough for +the benefit of the rest of the development team so that the problem never +happens again. It will happen again next month too, especially if you are +working on a project with other people who haven't yet internalized the +lessons you learned while you stepped through module-scope code using +``pdb``. Folks who have a large investment in eager decorator-based configuration that populates an external data structure (such as @@ -1593,7 +1585,7 @@ not logically global*: # this is executed if the request method was GET or the # credentials were invalid -The `Pylons <http://pylonshq.com>`_ web framework uses a similar +The `Pylons 1.X <http://pylonshq.com>`_ web framework uses a similar strategy. It calls these things "Stacked Object Proxies", so, for purposes of this discussion, I'll do so as well. diff --git a/docs/narr/declarative.rst b/docs/narr/declarative.rst index 086b6aa51..232f42751 100644 --- a/docs/narr/declarative.rst +++ b/docs/narr/declarative.rst @@ -1145,7 +1145,7 @@ which we assume lives in a ``subscribers.py`` module within your application: :linenos: <subscriber - for="pyramid.interfaces.INewRequest" + for="pyramid.events.NewRequest" handler=".subscribers.mysubscriber" /> diff --git a/docs/narr/events.rst b/docs/narr/events.rst index 0d0f96328..703b7bb88 100644 --- a/docs/narr/events.rst +++ b/docs/narr/events.rst @@ -3,6 +3,8 @@ single: subscriber single: INewRequest single: INewResponse + single: NewRequest + single: NewResponse .. _events_chapter: @@ -46,14 +48,14 @@ function found via a :term:`scan`. .. code-block:: python :linenos: - from pyramid.interfaces import INewRequest + from pyramid.events import NewRequest from subscribers import mysubscriber # "config" below is assumed to be an instance of a # pyramid.configuration.Configurator object - config.add_subscriber(mysubscriber, INewRequest) + config.add_subscriber(mysubscriber, NewRequest) The first argument to :meth:`pyramid.configuration.Configurator.add_subscriber` is the @@ -68,10 +70,10 @@ function found via a :term:`scan`. .. code-block:: python :linenos: - from pyramid.interfaces import INewRequest + from pyramid.events import NewRequest from pyramid.events import subscriber - @subscriber(INewRequest) + @subscriber(NewRequest) def mysubscriber(event): event.request.foo = 1 @@ -85,13 +87,16 @@ function found via a :term:`scan`. Either of the above registration examples implies that every time the :mod:`pyramid` framework emits an event object that supplies an -:class:`pyramid.interfaces.INewRequest` interface, the -``mysubscriber`` function will be called with an *event* object. +:class:`pyramid.events.NewRequest` interface, the ``mysubscriber`` function +will be called with an *event* object. -As you can see, a subscription is made in terms of an -:term:`interface`. The event object sent to a subscriber will always -be an object that possesses an interface. The interface itself -provides documentation of what attributes of the event are available. +As you can see, a subscription is made in terms of a *class* (such as +:class:`pyramid.events.NewResponse`). The event object sent to a subscriber +will always be an object that possesses an :term:`interface`. For +:class:`pyramid.events.NewResponse`, that interface is +:class:`pyramid.interfaces.INewResponse`. The interface documentation +provides information about available attributes and methods of the event +objects. The return value of a subscriber function is ignored. Subscribers to the same event type are not guaranteed to be called in any particular @@ -125,9 +130,9 @@ configuration startup: # config is an instance of pyramid.configuration.Configurator config.add_subscriber('myproject.subscribers.handle_new_request', - 'pyramid.interfaces.INewRequest') + 'pyramid.events.NewRequest') config.add_subscriber('myproject.subscribers.handle_new_response', - 'pyramid.interfaces.INewResponse') + 'pyramid.events.NewResponse') Either mechanism causes the functions in ``subscribers.py`` to be registered as event subscribers. Under this configuration, when the @@ -138,14 +143,12 @@ Each of our subscriber functions accepts an ``event`` object and prints an attribute of the event object. This begs the question: how can we know which attributes a particular event has? -We know that :class:`pyramid.interfaces.INewRequest` event objects -have a ``request`` attribute, which is a :term:`request` object, -because the interface defined at -:class:`pyramid.interfaces.INewRequest` says it must. Likewise, we -know that :class:`pyramid.interfaces.INewResponse` events have a +We know that :class:`pyramid.events.NewRequest` event objects have a +``request`` attribute, which is a :term:`request` object, because the +interface defined at :class:`pyramid.interfaces.INewRequest` says it must. +Likewise, we know that :class:`pyramid.interfaces.NewResponse` events have a ``response`` attribute, which is a response object constructed by your application, because the interface defined at :class:`pyramid.interfaces.INewResponse` says it must -(:class:`pyramid.interfaces.INewResponse` objects also have a -``request``). +(:class:`pyramid.events.NewResponse` objects also have a ``request``). diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst index 701cab17c..f8d662447 100644 --- a/docs/narr/hooks.rst +++ b/docs/narr/hooks.rst @@ -454,18 +454,18 @@ exists in :ref:`beforerender_event`. Using The Before Render Event ----------------------------- -Subscribers to the :class:`repoze.interfaces.IBeforeRender` event may -introspect the and modify the set of :term:`renderer globals` before they are -passed to a :term:`renderer`. This event object iself has a dictionary-like -interface that can be used for this purpose. For example: +Subscribers to the :class:`pyramid.events.BeforeRender` event may introspect +the and modify the set of :term:`renderer globals` before they are passed to +a :term:`renderer`. This event object iself has a dictionary-like interface +that can be used for this purpose. For example: .. code-block:: python :linenos: - from repoze.events import subscriber - from pyramid.interfaces import IBeforeRender + from pyramid.events import subscriber + from pyramid.events import BeforeRender - @subscriber(IBeforeRender) + @subscriber(BeforeRender) def add_global(event): event['mykey'] = 'foo' @@ -478,11 +478,11 @@ If a subscriber attempts to add a key that already exist in the renderer globals dictionary, a :exc:`KeyError` is raised. This limitation is enforced because event subscribers do not possess any relative ordering. The set of keys added to the renderer globals dictionary by all -:class:`pyramid.interfaces.IBeforeRender` subscribers and renderer globals +:class:`pyramid.events.BeforeRender` subscribers and renderer globals factories must be unique. -See the API documentation for the event interface -:class:`pyramid.interfaces.IBeforeRender`. +See the API documentation for the :class:`pyramid.events.BeforeRender` event +interface at :class:`pyramid.interfaces.IBeforeRender`. Another mechanism which allows event subscribers more control when adding renderer global values exists in :ref:`adding_renderer_globals`. @@ -521,16 +521,15 @@ response callback will be an exception object instead of its default value of ``None``. Response callbacks are called in the order they're added -(first-to-most-recently-added). All response callbacks are called -*after* the :class:`pyramid.interfaces.INewResponse` event is sent. -Errors raised by response callbacks are not handled specially. They -will be propagated to the caller of the :mod:`pyramid` router -application. +(first-to-most-recently-added). All response callbacks are called *after* +the :class:`pyramid.events.NewResponse` event is sent. Errors raised by +response callbacks are not handled specially. They will be propagated to the +caller of the :mod:`pyramid` router application. -A response callback has a lifetime of a *single* request. If you want -a response callback to happen as the result of *every* request, you -must re-register the callback into every new request (perhaps within a -subscriber of a :class:`pyramid.interfaces.INewRequest` event). +A response callback has a lifetime of a *single* request. If you want a +response callback to happen as the result of *every* request, you must +re-register the callback into every new request (perhaps within a subscriber +of a :class:`pyramid.events.NewRequest` event). .. _using_finished_callbacks: @@ -587,10 +586,10 @@ Errors raised by finished callbacks are not handled specially. They will be propagated to the caller of the :mod:`pyramid` router application. -A finished callback has a lifetime of a *single* request. If you want -a finished callback to happen as the result of *every* request, you -must re-register the callback into every new request (perhaps within a -subscriber of a :class:`pyramid.interfaces.INewRequest` event). +A finished callback has a lifetime of a *single* request. If you want a +finished callback to happen as the result of *every* request, you must +re-register the callback into every new request (perhaps within a subscriber +of a :class:`pyramid.events.NewRequest` event). .. _registering_configuration_decorators: diff --git a/docs/narr/router.rst b/docs/narr/router.rst index 6bc17caf0..b585482ef 100644 --- a/docs/narr/router.rst +++ b/docs/narr/router.rst @@ -32,8 +32,8 @@ processing? :func:`pyramid.threadlocal.get_current_request` and :func:`pyramid.threadlocal.get_current_registry` to work. -#. A :class:`pyramid.interfaces.INewRequest` :term:`event` is sent - to any subscribers. +#. A :class:`pyramid.events.NewRequest` :term:`event` is sent to any + subscribers. #. If any :term:`route` has been defined within application configuration, the :mod:`pyramid` :term:`router` calls a @@ -74,7 +74,7 @@ processing? they can be accessed via e.g. ``request.context`` within :term:`view` code. -#. A :class:`pyramid.interfaces.IContextFound` :term:`event` is +#. A :class:`pyramid.events.ContextFound` :term:`event` is sent to any subscribers. #. :mod:`pyramid` looks up a :term:`view` callable using the @@ -114,14 +114,13 @@ processing? #. The following steps occur only when a :term:`response` could be successfully generated by a normal :term:`view callable` or an - :term:`exception view` callable. :mod:`pyramid` will attempt to - execute any :term:`response callback` functions attached via + :term:`exception view` callable. :mod:`pyramid` will attempt to execute + any :term:`response callback` functions attached via :meth:`pyramid.request.Request.add_response_callback`. A - :class:`pyramid.interfaces.INewResponse` :term:`event` is then - sent to any subscribers. The response object's ``app_iter``, - ``status``, and ``headerlist`` attributes are then used to generate - a WSGI response. The response is sent back to the upstream WSGI - server. + :class:`pyramid.events.NewResponse` :term:`event` is then sent to any + subscribers. The response object's ``app_iter``, ``status``, and + ``headerlist`` attributes are then used to generate a WSGI response. The + response is sent back to the upstream WSGI server. #. :mod:`pyramid` will attempt to execute any :term:`finished callback` functions attached via diff --git a/docs/narr/startup.rst b/docs/narr/startup.rst index 53cbcd95c..7c4ee0897 100644 --- a/docs/narr/startup.rst +++ b/docs/narr/startup.rst @@ -121,9 +121,8 @@ press ``return`` after running ``paster serve development.ini``. configurator previously populated by other methods run against the Configurator. The router is a WSGI application. -#. A :class:`pyramid.interfaces.IApplicationCreated` event is - emitted (see :ref:`events_chapter` for more information about - events). +#. A :class:`pyramid.events.ApplicationCreated` event is emitted (see + :ref:`events_chapter` for more information about events). #. Assuming there were no errors, the ``app`` function in ``myproject`` returns the router instance created by ``make_wsgi_app`` back to diff --git a/docs/tutorials/wiki/installation.rst b/docs/tutorials/wiki/installation.rst index 9fff233c1..3e1b7552c 100644 --- a/docs/tutorials/wiki/installation.rst +++ b/docs/tutorials/wiki/installation.rst @@ -201,13 +201,13 @@ On UNIX: .. code-block:: bash - $ ../bin/paster serve tutorial.ini --reload + $ ../bin/paster serve development.ini --reload On Windows: .. code-block:: bat - c:\bifgfntut\tutorial> ..\Scripts\paster serve tutorial.ini --reload + c:\bifgfntut\tutorial> ..\Scripts\paster serve development.ini --reload Exposing Test Coverage Information ================================== diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst index ea4ca3bab..0826de660 100644 --- a/docs/tutorials/wiki2/definingviews.rst +++ b/docs/tutorials/wiki2/definingviews.rst @@ -297,7 +297,7 @@ something like so: .. literalinclude:: src/views/tutorial/__init__.py :linenos: - :language: xml + :language: python The WSGI Pipeline ----------------- diff --git a/docs/tutorials/wiki2/installation.rst b/docs/tutorials/wiki2/installation.rst index 2f103272a..37a99171f 100644 --- a/docs/tutorials/wiki2/installation.rst +++ b/docs/tutorials/wiki2/installation.rst @@ -205,13 +205,13 @@ On UNIX: .. code-block:: text - $ ../bin/paster serve tutorial.ini --reload + $ ../bin/paster serve development.ini --reload On Windows: .. code-block:: text - c:\bifgfntut\tutorial> ..\Scripts\paster serve tutorial.ini --reload + c:\bifgfntut\tutorial> ..\Scripts\paster serve development.ini --reload Exposing Test Coverage Information ================================== diff --git a/docs/zcml/subscriber.rst b/docs/zcml/subscriber.rst index c48c89a9b..c04aecff2 100644 --- a/docs/zcml/subscriber.rst +++ b/docs/zcml/subscriber.rst @@ -11,12 +11,11 @@ Attributes ~~~~~~~~~~ ``for`` - The class or :term:`interface` that you are subscribing the - listener for, e.g. :class:`pyramid.interfaces.INewRequest`. - 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). + 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 @@ -30,7 +29,7 @@ Examples :linenos: <subscriber - for="pyramid.interfaces.INewRequest" + for="pyramid.events.NewRequest" handler=".subscribers.handle_new_request" /> diff --git a/pyramid/configuration.py b/pyramid/configuration.py index 805894ce4..b392b2163 100644 --- a/pyramid/configuration.py +++ b/pyramid/configuration.py @@ -617,7 +617,7 @@ class Configurator(object): def make_wsgi_app(self): """ Returns a :mod:`pyramid` WSGI application representing the current configuration state and sends a - :class:`pyramid.interfaces.IApplicationCreated` + :class:`pyramid.events.ApplicationCreated` event to all listeners.""" from pyramid.router import Router # avoid circdep app = Router(self.registry) diff --git a/pyramid/events.py b/pyramid/events.py index 043631539..d6026413b 100644 --- a/pyramid/events.py +++ b/pyramid/events.py @@ -17,10 +17,10 @@ class subscriber(object): .. code-block:: python - from pyramid.interfaces import INewRequest + from pyramid.events import NewRequest from pyramid.events import subscriber - @subscriber(INewRequest) + @subscriber(NewRequest) def mysubscriber(event): event.request.foo = 1 @@ -28,10 +28,10 @@ class subscriber(object): .. code-block:: python - from pyramid.interfaces import INewRequest + from pyramid.events import NewRequest, NewResponse from pyramid.events import subscriber - @subscriber(INewRequest, INewResponse) + @subscriber(NewRequest, NewResponse) def mysubscriber(event): print event @@ -40,7 +40,6 @@ class subscriber(object): .. code-block:: python - from pyramid.interfaces import INewRequest from pyramid.events import subscriber @subscriber() diff --git a/pyramid/request.py b/pyramid/request.py index 76fff37a8..d18b07cc2 100644 --- a/pyramid/request.py +++ b/pyramid/request.py @@ -70,7 +70,7 @@ class Request(WebobRequest): response object returned by :term:`view` code is invalid. All response callbacks are called *after* the - :class:`pyramid.interfaces.INewResponse` event is sent. + :class:`pyramid.events.NewResponse` event is sent. Errors raised by callbacks are not handled specially. They will be propagated to the caller of the :mod:`pyramid` diff --git a/pyramid/url.py b/pyramid/url.py index 9d94a44f5..ce7eee8d5 100644 --- a/pyramid/url.py +++ b/pyramid/url.py @@ -17,12 +17,12 @@ from pyramid.traversal import quote_path_segment def route_url(route_name, request, *elements, **kw): """Generates a fully qualified URL for a named :mod:`pyramid` :term:`route configuration`. - + Use the route's ``name`` as the first positional argument. Use a request object as the second positional argument. Additional positional arguments are appended to the URL as path segments after it is generated. - + Use keyword arguments to supply values which match any dynamic path elements in the route definition. Raises a :exc:`KeyError` exception if the URL cannot be generated for any reason (not @@ -34,9 +34,9 @@ def route_url(route_name, request, *elements, **kw): route_url('foobar', request, foo='1') => <KeyError exception> route_url('foobar', request, foo='1', bar='2') => <KeyError exception> route_url('foobar', request, foo='1', bar='2', - 'traverse=('a','b')) => http://e.com/1/2/a/b + traverse=('a','b')) => http://e.com/1/2/a/b route_url('foobar', request, foo='1', bar='2', - 'traverse=('/a/b')) => http://e.com/1/2/a/b + traverse='/a/b') => http://e.com/1/2/a/b Values replacing ``:segment`` arguments can be passed as strings or Unicode objects. They will be encoded to UTF-8 and URL-quoted |