On Nov 14, 2007 3:00 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
...
> And no, I'm not making a ticket for it yet, because it occurred to me
> while working on it, that it doesn't require any changes to
> PyDispatcher itself. That means, Jeremy, that you can just drop this
> somewhere and use it
On Nov 14, 2007 8:55 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
> I dunno, that's all just off the top of my head, but maybe it could work.
Well, I did a little digging and put together something that seems to
work. And when I say "seems to work", I mean that there are almost 100
lines of
Hi,
> On Nov 14, 2007 9:37 AM, Forest Bond <[EMAIL PROTECTED]> wrote:
> > This is neat and all, but I don't think at actually solves the problem at
> > hand.
> > If save is not overridden, when does queue.dispatch() get called?
>
> If save isn't overridden, queue.dispatch() wouldn't be called,
On Nov 14, 2007 9:37 AM, Forest Bond <[EMAIL PROTECTED]> wrote:
> This is neat and all, but I don't think at actually solves the problem at
> hand.
> If save is not overridden, when does queue.dispatch() get called?
If save isn't overridden, queue.dispatch() wouldn't be called, because
the
On Wed, Nov 14, 2007 at 08:55:09AM -0500, Marty Alchin wrote:
> On Nov 14, 2007 12:21 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > Jeremy's still got a valid problem, though, but I'm not sure
> > reintroducing pre_save() and post_save() is a necessary step yet.
> > Hopefully there's
And, of course, adding a queue to the dispatcher would decouple this
solution from save() and make it usable in any signal handling code.
-Gul
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
On Nov 14, 2007 12:21 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Jeremy's still got a valid problem, though, but I'm not sure
> reintroducing pre_save() and post_save() is a necessary step yet.
> Hopefully there's something else we can do.
I wonder if there's a way to modify
On Tue, 2007-11-13 at 22:58 -0600, Gary Wilson wrote:
[...]
> I would think most use cases for overriding save() involve doing something
> before or after the actual saving of the object. In other words, having a
> pre_save() and post_save() means that few people would need to override save()
>
James Bennett wrote:
> On 11/13/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
>> How about introducing pre_save and/or post_save methods. The signal firing
>> happens in pre_save and post_save. You can override whatever you want -
>> pre_save, save, or post_save depending on your needs. This
On 11/13/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
> How about introducing pre_save and/or post_save methods. The signal firing
> happens in pre_save and post_save. You can override whatever you want -
> pre_save, save, or post_save depending on your needs. This would also allow
> you to
Jeremy Dunck wrote:
> On Nov 13, 2007 10:02 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>> Personally, I'm comfortable with documenting the fact that if
>> Model.save() is never called, the pre_save and post_save signals will
>> never fire (same is true of overridden __init__() and the post_init
On Nov 13, 2007 10:02 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 11/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > Perhaps Model.save(raw=False) should become Model.save(raw=False,
> > fire_signals=True), leaving it up to the overrider to decide the
> > policy?
>
> Personally, I'm
On 11/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> Perhaps Model.save(raw=False) should become Model.save(raw=False,
> fire_signals=True), leaving it up to the overrider to decide the
> policy?
Personally, I'm comfortable with documenting the fact that if
Model.save() is never called, the
Jeremy Dunck said the following:
> I feel OK about having to manually call post_save when I override
> Model.save, but adding it now just results in post_save being called
> twice.
Couldn't you just fire your own signal? :)
--
Collin Grady
--~--~-~--~~~---~--~~
I have a few places that override Model.save to do additional work
after the normal functionality.
I needed to add a post_save handler to do even more stuff after that
additional work, but ran into the obvious problem: post_save is
called at the end of Model.save, and that's before the
15 matches
Mail list logo
