Changes between Version 20 and Version 21 of Signals

Timestamp:

Mar 29, 2008, 2:55:03 AM (17 years ago)

Author:

Michael Koloberdin

Comment:

create_contenttypes -> update_contenttypes

Signals

@@ -56 +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.
 
-In its `management.py` file, the contenttypes app defines a function called `create_contenttypes`, which takes three arguments: `app`, `created_models` and `verbosity`. These correspond to the extra arguments `manage.py` will use with `dispatcher.send` when it sends the `post_syncdb` signal after installing each new application, and provide enough information to determine which models need to have new `ContentType` objects created (actually, just `app` and `created_models` would be enough; the extra argument, `verbosity`, is used by `manage.py` to indicate whether any listening functions should be "verbose" and echo output to the console, or be quiet and not echo any output.
-
-The `management.py` file also imports `django.db.models.signals` and `django.dispatch.dispatcher`; after the `create_contenttypes` function is defined, it sets up that function to listen for the `post_syncdb` signal:
-
-{{{
-dispatcher.connect(create_contenttypes, signal=signals.post_syncdb)
-}}}
-
-The first argument, `create_contenttypes`, is the name of the function to execute when the signal is sent out. The second argument, `signal`, is the signal to listen for. There is another optional argument, `sender`, which is not used in this example; `sender` can be used to narrow down exactly what will be listened for; when you specify `sender`, your function will only be executed when the object which sent the signal is the same as the object you specify as the `sender` argument.
+In its `management.py` file, the contenttypes app defines a function called `update_contenttypes`, which takes three arguments: `app`, `created_models` and `verbosity`. These correspond to the extra arguments `manage.py` will use with `dispatcher.send` when it sends the `post_syncdb` signal after installing each new application, and provide enough information to determine which models need to have new `ContentType` objects created (actually, just `app` and `created_models` would be enough; the extra argument, `verbosity`, is used by `manage.py` to indicate whether any listening functions should be "verbose" and echo output to the console, or be quiet and not echo any output.
+
+The `management.py` file also imports `django.db.models.signals` and `django.dispatch.dispatcher`; after the `update_contenttypes` function is defined, it sets up that function to listen for the `post_syncdb` signal:
+
+{{{
+dispatcher.connect(update_contenttypes, signal=signals.post_syncdb)
+}}}
+
+The first argument, `update_contenttypes`, is the name of the function to execute when the signal is sent out. The second argument, `signal`, is the signal to listen for. There is another optional argument, `sender`, which is not used in this example; `sender` can be used to narrow down exactly what will be listened for; when you specify `sender`, your function will only be executed when the object which sent the signal is the same as the object you specify as the `sender` argument.
 
 An example of this can be found in Django's authentication application: `django.contrib.auth.management` defines a function called `create_superuser`, and uses the dispatcher to connect to the `post_syncdb` signal -- but ''only'' when `post_syncdb` is being sent as a result of installing the auth application. To do this, the auth app's `management.py` file imports its own models: