Hi, On Thu, 15 Nov 2012 18:15:37 +0100 Carsten Fuchs <carsten.fu...@cafu.de> wrote: > Am 15.11.2012 17:52, schrieb Arnold Krille: > > On Thursday 15 November 2012 17:12:09 Carsten Fuchs wrote: > >> [...] > >> (Note that it is not enough to consider the Period that changed -- > >> rather, it is the 'end' in *another* period (the one "before" it) > >> that must be modified and saved, too.) > >> What is the proper hook or where the best place to do this? > > 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. > Well, I realize that this would be useful also generically, outside > of the admin interface.
Even if you do not need it outside the admin-interface (in this project), from the logic this belongs to the model, not into some view. > Alas, if e.g. I overrode the save() method of the Period class, is it > safe to access *another* Period instance from there? Yep, thats save. If you use a db that has transactions, both the change to the other object should be rolled back when saving of the current objects fails as it should all end up in one transaction. :-) > I don't really fully understand how the admin interface works when a > model with inlines is saved, but I suspect that the inlines are saved > in a loop. But if in an early iteration of the loop I modified > another instance that is routinely saved *again* in a later iteration > of the loop, it will be a bug. I can't really comment on the admin interfaces working as we use that only for the stuff only a superuser has rights. Everything else is edited in our frontend-code. But saving inlines in the admin interface should be the same as saving forms with formsets underneath. Have fun, Arnold
signature.asc
Description: PGP signature
