Changes between Version 18 and Version 19 of Signals
- Timestamp:
- Dec 20, 2007, 11:27:34 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Signals
v18 v19 49 49 To listen for a signal, first define a function that you want to execute when the signal is sent; if you know that the signal will be sent with extra arguments and you want to use those arguments, make sure your function accepts them. Then you need to do three things: 50 50 51 1. Import the signal object you'll be listening for. 52 2. Import the dispatcher. 53 3. Use the dispatcher's `connect` signal to tell the dispatcher you want to listen for something. 51 1. Make sure there is a reference to your signal handler somewhere. If it is defined as a local function, chances are it will be garbage collected and won't receive any signals. 52 2. Import the signal object you'll be listening for. 53 3. Import the dispatcher. 54 4. Use the dispatcher's `connect` signal to tell the dispatcher you want to listen for something. 54 55 55 56 A good example of this is found in Django's bundled "contenttypes" application, which creates and maintains a registry of all the installed models in your database. In order to do this, the contenttypes app defines a `ContentType` model, and it needs to know any time a new model is installed so it can create the appropriate `ContentType` object for that model. To do this, it includes a file called `management.py`; whenever `manage.py syncdb` is run, it loops through ''every'' application in the `INSTALLED_APPS` setting, and looks to see if any apps contain a module called `management`; if they do, `manage.py` imports them before installing any models, which means that any dispatcher connections listed in an app's `management` module will be set up before model installation happens.