On Mon, Aug 17, 2009 at 1:44 PM, Jacob Kaplan-Moss wrote:
>
> On Mon, Aug 17, 2009 at 9:10 AM, Joshua Russo
> wrote:
> > I will try hooking into both post_save and post_delete signals though I
> was
> > looking for a more unified approach, to avoid repetition.
>
> You may already know this, but yo
On Mon, Aug 17, 2009 at 9:10 AM, Joshua Russo wrote:
> I will try hooking into both post_save and post_delete signals though I was
> looking for a more unified approach, to avoid repetition.
You may already know this, but you can hook the same method up to
multiple signals::
def handle_save_
Oh that's right, reason I put this in ModelAdmin is because I'm clearing
session variables and so I need the request object. (So signals won't work.
I don't believe.) When dealing with the request object there isn't a real
clean way to centralize management like this. By adding the model_modified
h
The problem with simply extending the save method is that it doesn't cover
deletes.
I will try hooking into both post_save and post_delete signals though I was
looking for a more unified approach, to avoid repetition.
On Mon, Aug 17, 2009 at 12:11 PM, Marc Remolt wrote:
>
> May I ask why you don
May I ask why you don't simply extend the models save method or use a
post save signal
(http://docs.djangoproject.com/en/dev/ref/signals/#django.db.models.signals.post_save)?
Do you really want the cleanups only if the object is saved via the
admin or whenever it is saved - for example in your
I've implemented a simple hook called model_modified() that can be extended
in the user's ModelAdmin class. It's called after a New, Update, or Delete
action is taken. I've used it in my application to clear related session
information that I use to cache heavy query results.
Does this sound like a
