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.
For now, I'm calling this the class ManyToManyHelper, though I'm not in any way married to it. I just don't want it to be called a Manager, since it's not actually one on its own. It provides add(), remove(), clear() and create(), so that each of these can be overridden to provide additional functionality before and/or after the "real" work is done. It's passed to a ManyToManyField with a new "helper" argument, which would default to the standard ManyToManyHelper if not defined. The real trouble with this approach (so far) is that there's some question about which side of the relationship you're working from. For instance, if you override add() to enforce a maximum number of relationships, it should be checked on both sides: when you add A to B and when you add B to A. However, if just one helper class is used, "self.instance" could be an instance of either model, so you'd have to test for the model class and include two separate queries for essentially the same task. This isn't the DRY you're looking for. Move along. I have some other ideas on the subject, but I thought I'd report what I've done so far anyway, and what I've run into. Does anybody else with knowledge of related fields and a desire to see this happen want to chime in? -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 -~----------~----~----~----~------~----~------~--~---