summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorMichael Merickel <michael@merickel.org>2013-08-12 16:26:19 -0500
committerMichael Merickel <michael@merickel.org>2013-08-12 16:26:19 -0500
commit084f12252356879b7d4cad085d64e1f0d3679cd1 (patch)
treeb01df513fd6bd1d834e7da9bd2a5e8616b52be45 /docs
parent486dd8a441a17a6b88340eaf293b808c4e0c138b (diff)
parent970dfae46bb398e862f57d89c3f6efe10c45e715 (diff)
downloadpyramid-084f12252356879b7d4cad085d64e1f0d3679cd1.tar.gz
pyramid-084f12252356879b7d4cad085d64e1f0d3679cd1.tar.bz2
pyramid-084f12252356879b7d4cad085d64e1f0d3679cd1.zip
Merge branch 'master' of latteier/pyramid into pull/1079
Diffstat (limited to 'docs')
-rw-r--r--docs/api/registry.rst9
-rw-r--r--docs/narr/events.rst87
2 files changed, 93 insertions, 3 deletions
diff --git a/docs/api/registry.rst b/docs/api/registry.rst
index db348495c..42a405a32 100644
--- a/docs/api/registry.rst
+++ b/docs/api/registry.rst
@@ -29,6 +29,15 @@
This attribute is often accessed as ``request.registry.introspector`` in
a typical Pyramid application.
+ .. method:: notify(*events)
+
+ Fire one or more events. All event subscribers to the event(s)
+ will be notified. The subscribers will be called synchronously on
+ the current thread. This method is often accessed as
+ ``request.registry.notify`` in Pyramid applications to fire
+ custom events. See :ref:`custom_events` for more information.
+
+
.. class:: Introspectable
.. versionadded:: 1.3
diff --git a/docs/narr/events.rst b/docs/narr/events.rst
index 929208083..5004a1787 100644
--- a/docs/narr/events.rst
+++ b/docs/narr/events.rst
@@ -53,7 +53,7 @@ method (see also :term:`Configurator`):
from subscribers import mysubscriber
- # "config" below is assumed to be an instance of a
+ # "config" below is assumed to be an instance of a
# pyramid.config.Configurator object
config.add_subscriber(mysubscriber, NewRequest)
@@ -77,7 +77,7 @@ type via the :func:`pyramid.events.subscriber` function.
@subscriber(NewRequest)
def mysubscriber(event):
- event.request.foo = 1
+ event.request.foo = 1
When the :func:`~pyramid.events.subscriber` decorator is used a
:term:`scan` must be performed against the package containing the
@@ -113,7 +113,7 @@ your application like so:
:linenos:
def handle_new_request(event):
- print 'request', event.request
+ print 'request', event.request
def handle_new_response(event):
print 'response', event.response
@@ -150,3 +150,84 @@ application, because the interface defined at
:class:`pyramid.interfaces.INewResponse` says it must
(:class:`pyramid.events.NewResponse` objects also have a ``request``).
+.. _custom_events:
+
+Creating Your Own Events
+------------------------
+
+In addition to using the events that the Pyramid framework creates,
+you can create your own events for use in your application. This can
+be useful to decouple parts of your application.
+
+For example, suppose your application has to do many things when a new
+document is created. Rather than putting all this logic in the view
+that creates the document, you can create the document in your view
+and then fire a custom event. Subscribers to the custom event can take
+other actions, such as indexing the document, sending email, or
+sending a message to a remote system.
+
+An event is simply an object. There are no required attributes or
+method for your custom events. In general, your events should keep
+track of the information that subscribers will need. Here are some
+example custom event classes:
+
+.. code-block:: python
+ :linenos:
+
+ class DocCreated(object):
+ def __init__(self, doc, request):
+ self.doc = doc
+ self.request = request
+
+ class UserEvent(object):
+ def __init__(self, user):
+ self.user = user
+
+ class UserLoggedIn(UserEvent):
+ pass
+
+Some Pyramid applications choose to define custom events classes in an
+``events`` module.
+
+You can subscribe to custom events in the same way that you subscribe
+to Pyramid events -- either imperatively or with a decorator. You can
+also use custom events with :ref:`subscriber predicates
+<subscriber_predicates>`. Here's an example of subscribing to a custom
+event with a decorator:
+
+.. code-block:: python
+ :linenos:
+
+ from pyramid.events import subscriber
+ from .events import DocCreated
+ from .index import index_doc
+
+ @subscriber(DocCreated)
+ def index_doc(event):
+ # index the document using our application's index_doc function
+ index_doc(event.doc, event.request)
+
+The above example assumes that the application defines a
+``DocCreated`` event class and an ``index_doc`` function.
+
+To fire your custom events use the
+:meth:`pyramid.registry.Registry.notify` method, which is most often
+accessed as ``request.registry.notify``. For example:
+
+.. code-block:: python
+ :linenos:
+
+ from .events import DocCreated
+
+ def new_doc_view(request):
+ doc = MyDoc()
+ event = DocCreated(doc, request)
+ request.registry.notify(event)
+ return {'document': doc}
+
+This example view will notify all subscribers to the custom
+``DocCreated`` event.
+
+Note that when you fire an event, all subscribers are run
+synchronously on the current thread. So it's generally not a good idea
+to create event handlers that may take a long time to run.