"hacks, signals, and/or patches" One of these things is not like the other.
The signals framework is made for precisely for cases like the one you describe. Why do you compare it to hacks / patches? Your signal can be utterly DRY and you can write unit tests for it (although, if you are using a template in the callable, you may fall prey to the problem I tried to patch in #17032). In every way I am currently able to contemplate, using a signal is more straightforward and decoupled than the solution you propose. I may well be missing something; please point it out if that's so. On Sun, Dec 4, 2011 at 11:28 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote: >> Or is your main objection having to branch against the specific > > Simply put, there should be an *optional* way to ensure a model's > *explicitly* defined delete behavior is honored without having to > write hacks, signals, and/or patches of any kind (ie, make it DRY, and > therefore less error-prone). This seems like common sense, so I really > don't know how much more I can clarify the topic. > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- Justin Holmes Head Instructor, SlashRoot Collective SlashRoot: Coffee House and Tech Dojo 60 Main Street New Paltz, NY 12561 845.633.8330 -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
