Changes between Version 33 and Version 34 of Signals


Ignore:
Timestamp:
Oct 17, 2008, 7:08:48 AM (17 years ago)
Author:
Thomas Güttler
Comment:

Don't repeat yourself: The signal reference contains the list of signals.

Legend:

Unmodified
Added
Removed
Modified

  • Signals

    v33 v34  
    8282Django defines several sets of signals which are used internally, and which you can listen for in order to run your own custom code at specific moments.
    8383
    84 `django.db.models.signals` defines the following signals:
    85 
    86 '''class_prepared'''
    87 
    88 This is sent whenever a model class has been "prepared"; in other words, once most of the metaprogramming which makes models work has been completed. Django uses this signal internally to know when to generate and add the automatic `AddManipulator` and `ChangeManipulator` to a model class (see the DevModelCreation page for details).
    89 
    90 Arguments that are sent with this signal:
    91 
    92  * `sender` -- the model class which was just prepared.
    93 
    94 '''pre_init'''
    95 
    96 Whenever you create a new instance of a Django model (for example, in [http://www.djangoproject.com/documentation/tutorial1/ the first part of the Django tutorial] when you do `p = Poll(question="What's up?", pub_date=datetime.now())`) , this signal is sent at the beginning of the execution of the model's `__init__` method. '''Note:''' if you override `__init__` on your model, you must call the parent class' `__init__` method for this signal to be sent, and it will be sent at the beginning of the parent class' `__init__` method.
    97 
    98 Arguments sent with this signal:
    99 
    100  * `sender` -- the model class you're creating an instance of.
    101  * `args` -- a list of positional arguments passed to the model's `__init__` method.
    102  * `kwargs` -- a dictionary of keyword arguments passed to the model's `__init__` method. For example, in the tutorial when you do `p = Poll(question="What's up?", pub_date=datetime.now())`, the `kwargs` argument to the `pre_init` signal would be the dictionary `{'question': "What's up?", 'pub_date': datetime.now()}`.
    103 
    104 '''post_init'''
    105 
    106 Like `pre_init`, but this one is sent when the model's `__init__` method is done executing. '''Note:''' if you override `__init__` on your model, you must call the parent class' `__init__` method for this signal to be sent, and it will be sent at the end of the parent class' `__init__` method.
    107 
    108 Arguments sent with this signal:
    109 
    110  * `sender` -- the model class you've just created an instance of.
    111  * `instance` -- the instance of the model you just created. For example, in the tutorial when you do `p = Poll(question="What's up?", pub_date=datetime.now())`, the `instance` argument to the `post_init` signal would be the `Poll` object you just created.
    112 
    113 '''pre_save'''
    114 
    115 This is sent at the beginning of a model's `save` method. '''Note:''' if you override `save` on your model, you must call the parent class' `save` method for this signal to be sent, and it will be sent at the beginning of the parent class' `save` method.
    116 
    117 Arguments sent with this signal:
    118 
    119  * `sender` -- the model class of the object being saved.
    120  * `instance` -- the actual object being saved.
    121  * `raw` -- raw save, save the object exactly as presented.
    122 
    123 '''post_save'''
    124 
    125 This is sent at the end of a model's `save` method. '''Note:''' if you override `save` on your model, you must call the parent class' `save` method for this signal to be sent, and it will be sent at the end of the parent class' `save` method.
    126 
    127 Arguments sent with this signal:
    128 
    129  * `sender` -- the model class of the object which was just saved.
    130  * `instance` -- the actual object which was just saved.
    131  * `created` -- a boolean. True if a new record was create.
    132  * `raw` -- raw save, save the object exactly as presented.
    133 
    134 '''pre_delete'''
    135 
    136 This is sent at the beginning of a model's `delete` method. '''Note:''' if you override `delete` on your model, you must call the parent class' `delete` method for this signal to be sent, and it will be sent at the beginning of the parent class' `delete` method.
    137 
    138 
    139 Arguments sent with this signal:
    140 
    141  * `sender` -- the model class of the object which is about to be deleted.
    142  * `instance` -- the actual object which is about to be deleted.
    143 
    144 '''post_delete'''
    145 
    146 This is sent at the end of a model's `delete` method. '''Note:''' if you override `delete` on your model, you must call the parent class' `delete` method for this signal to be sent, and it will be sent at the beginning of the parent class' `delete` method.
    147 
    148 
    149 Arguments sent with this signal:
    150 
    151  * `sender` -- the model class of the object which was just deleted.
    152  * `instance` -- the actual object which was just deleted (the object will no longer be in the database, but will stick around in memory for a little while after that).
    153 
    154 '''post_syncdb''
    155 
    156 Sent by `manage.py syncdb` after it installs an application.
    157 
    158 Arguments sent with this signal:
    159 
    160  * `sender` -- the `models` module of the application which was just installed.
    161  * `app` -- same as `sender`.
    162  * `created_models` -- a list of the model classes which `manage.py` has created so far, regardless of app.
    163  * `verbosity` -- indicates how much information `manage.py` is printing on screen. There are three possible values: 0 means no information, 1 means some information and 2 means all possible information. Functions which listen for this signal should adjust what they output to the screen based on the value of this argument.
    164  * `interactive` -- whether `manage.py` is running in "interactive" mode; this is a boolean and so is either `True` or `False`. If `interactive` is `True`, it's safe to prompt the user to input things on the command line (for example, the auth app only prompts to create a superuser when `interactive` is `True`); if `interactive` is `False`, functions which listen for this signal should not try to prompt for anything.
    165 
    166 ----
    167 
    168 `django.core.signals` defines the following signals:
    169 
    170 '''request_started'''
    171 
    172 This signal is sent whenever Django begins processing an incoming HTTP request.
    173 
    174 This signal doesn't provide any arguments.
    175 
    176 '''request_finished'''
    177 
    178 This signal is sent whenever Django finishes processing an incoming HTTP request.
    179 
    180 This signal doesn't provide any arguments.
    181 
    182 '''got_request_exception'''
    183 
    184 This signal is sent whenever Django encounters an exception while processing an incoming HTTP request.
    185 
    186 This signal doesn't provide any arguments.
    187 
    188 ----
    189 
    190 `django.test.signals` defines the following signals:
    191 
    192 '''template_rendered'''
    193 
    194 This signal is sent by Django's testing framework whenever the test system renders a template; it's used by the test system to verify that the template rendered as expected. This signal is not emitted during normal operation of a Django server -- it is only available during testing.
    195 
    196 Arguments sent with this signal:
    197 
    198  * `sender` -- the `Template` object which was rendered.
    199  * `template` -- same as `sender`.
    200  * `context` -- the `Context` with which the template was rendered.
     84[http://docs.djangoproject.com/en/dev/ref/signals/ See built-in signal reference]
    20185
    20286== Refactoring differences ==
Back to Top