Written by Martin Geber on October 29, 2007 at 10:17 p.m.
Filed unter: Django.
2 Comments.
Trackback URL.
The more I read about Django signals (didn't set up one yet), the more I wonder where the difference between a post_save or pre_save signal and the redefinition of the save-method is.
In case you know what signals are and you know what I mean with the redefinition of the save-method, skip the following paragraphs.
Signals are actions, which you can listen to. When you, for example, want to get an email the next time someone writes a comment (commonly some spam-robot, but anyway), then you can write a small piece of code that comes into action, whenever a new comment flies into you database.
But this post doesn't try to explain signals. I just can recommend the white paper by Mercurytid about Django's signals. (It really is excellent.)
In Django you commonly create models, where all your data is stored. These models inherit form models.Model, which has a save-method. As usual in Python you can change parent's methods. To use their abilities you can call them using super(). An example of this is below.
When you define a model, you are able to customize the save-method in the same way signals would work. In case you are not aware of what I mean, here is an example:
from django.utils.translation import gettext_lazy as _
from django.db import models
class Car(models.Model):
manufacturer = models.CharField(_('Manufacturer'), max_length=30)
model = models.CharField(_('Model'), max_length=20)
colour = models.PositiveSmallIntegerField(_('Color'), choices=((1, 'red'),
(2, 'blue'),
(3, 'green'),
(4, 'yellow'),))
def save(self):
# Place code here, which is excecuted the same
# time the ``pre_save``-signal would be
# Call parent's ``save`` function
super(Car, self).save()
# Place code here, which is excecuted the same
# time the ``post_save``-signal would be
It is quite obvious that dispatcher.connect(do_great_stuff, sender=Car, signal=signals.pre_save) and dispatcher.connect(do_great_stuff, sender=Car, signal=signals.post_save) are represented in the customized save-method.
As you can see in the source code above: It is implementable to use either signals or save-method redefinition. And I guess there is no real difference at all.
But when it comes to object-orientation, we have to ask ourselves, is it OK to put the email-sender into the saving procedure of the comment-model? And here it comes clear I guess.
-
you check given values
-
you create directories or files (directly connected to the data model)
e.g. I create a new directory for each new Memory
-
you are auto-populating fields, like James Bennett explains.
-
you do any action directly connected to the model you are operating on
-
you want to report that something was added or changed
-
you want to save new data-sets, which are associated to this model
-
e.g. when a new user is added to the system and you want to set the the default values of the website-settings (in case it is separated from
User and UserProfile)
-
e.g. when a new user is added and you want to save a Welcome! Message into the internal Private Messaging system
I said in the introduction that I didn't set-up a signal yet. This is true, but after this entry I should write one. This is because I have to admit that I send trackbacks and pingbacks from my Entry's save-method.
I hope this entry makes things clear to you. In case you disagree with me or you have another general example for either signals or save-method-redefinition, let me know by leaving a comment.
The comments also include all Trackbacks.
Eren commented, on January 31, 2008 at 8:14 a.m.:
Great document. It's clearlary understandable where to use "overritten save()" method or "signals".
Maybe, other people want to see a real example of signals. Just checkout django's test script on http://code.djangoproject.com/browser...