Code

Changes between Version 33 and Version 34 of Signals


Ignore:
Timestamp:
10/17/08 05:08:48 (6 years ago)
Author:
guettli
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 ==