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 queue wouldn't even exist. Signals would just be dispatched the same way they normally are. Even most overrides of save() still wouldn't need to deal with the queue, it'd only be necessary if someone actively needed to delay dispatches in code they don't control. > The only way I can think of overcoming this is to dynamically modify self.save > when it is accessed (by overriding __getattr__). The signals are fired from > code that is dynamically appended to the save method. This guarrantees that > the > signal is fired at the very end of the save call: You're right, this adds extra overhead, and I don't think it's necessary, to be honest. Yeah, using the queue does imply some risk that somebody might set up a queue and not dispatch it, or that they might forget to use the queue in the first place if they need it, but it's not the responsibility of the framework to prevent people from making coding mistakes. Down that path is Java. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
