Marty Alchin wrote: > I've come up with a considerably different approach to this, which > offers more flexibility, and also solves a problem I've had when it > comes to ManyToManyField. Basically, instead of dealing with signals, > and worrying about pre/post and whether or not you can prevent stuff, > I broke out some bits of ManyRelatedManager into a separate mix-in, > which can be subclassed.
[snip] Sounds like a very flexible approach, definitely more easy to use than signals. The problem you mention with having to check which side of the relationship you are working on in the custom mixin does not apply to signals, as the sender objects are different and you can register different functions for each one of them. The only advantage I see in adding signals (but I'm not an expert of Django internals) is that it's pretty painless as it's five-lines patch, and it leaves all the other code unchanged. A possible short-term solution could be to apply the signals patch now, then when/if you implement mix-ins, add a custom one that uses signals so that people relying on them do not have to modify their code, but can simply pass the mix-in to the M2M field. They will then be able to gracefully migrate to a (possibly) cleaner solution writing their own mix-in. Ludo --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
