Re: How to implement pre-save operations for inlines in the admin interface?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlClgkIACgkQuYLL1cDjHx0hUwCfW+8nlUqfE/N+Lcgl47/Ijnwb
wq4AnA20ONUicGb3sFl2XbQZj1PVKU11
=2oiG
-----END PGP SIGNATURE-----
On Fri, 16 Nov 2012 08:43:04 +1100 Mike Dewhirst
<miked@dewhirst.com.au> wrote:
> On 16/11/2012 3:52am, Arnold Krille wrote:
> > Why do you want to do this only in the admin interface?
> > Its a generic thing: every time you save/change a period you should
> > set the end-date of the previous one. So I would do this with a
> > post-save hook (aka signal) directly in the models.py. Or maybe
> > even subclass your models save- operation.
>
> This is a question not a competing opinion.
>
> Why would you use a post-save signal? Why not just override save()
> and use the model manager directly to find the previous period and if
> it doesn't have and end date pop one in?

I don't have the ultimate answer.

We have a case here where we apply one function to several models, on
one model on pre-save-signal and on several models on post-save-signal.
We could have done the same by subclassing all these models from one
abstract base which would have had one field and the save-function. The
signals seemed easier to us with less clutter in the model-graph.

For the case presented by Carsten, I am even more open to do it with
overwriting the save-function.
With the save-function you have the functionality directly where it
belongs.
With a post-save-signal you have maybe a bit cleaner kind of
code: the save-function of the object is only the save-function of the
object. The modification of a different object is in a different
function that has its execution-definition written directly above.

But its a matter of personal taste I think.

Have fun,

Arnold