I totally agree that signals are open to misuse, and I take your points. Inexperienced developers often seem to use them just because they're there, rather than to encapsulate their apps and avoid circular dependencies. The Django signals documentation could probably do with a bit more guidance of when to use them. On the other hand, I have seen a lot of great uses of models signals too.
There are other solutions, and I've actually given a talk about these here (https://skillsmatter.com/skillscasts/7129-encapsulated-django-keeping-your-apps-small-focused-and-free-of-circular-dependencies). The idea of OVERLOADED_CLASSES above is also a really interesting idea, but a lot more of a fundamental shift than just dispatching a few signals from the existing form classes. What I would say in terms of form signals support is that in a former life I was a Drupal developer. That framework has shortcomings but there are also things that work really well, and one of the best is a hook for altering forms (hook_form_alter) which works very well for Drupal's highly modular approach. This hook is used everywhere in Drupal projects. I think exposing this kind of hook would make it a lot easier for Django developers to architect their projects as small, pluggable apps - something that is pretty difficult to make work with forms. David On Monday, 6 March 2017 21:43:47 UTC, contact wrote: > > Hi ! > I'd prefer to that a standardized way of overloading classes, like with > a proper setting : > OVERLOADED_CLASSES = { > 'app.forms.MyForm': 'myapp.forms.MyForm' > } > Having (or not) myapp.forms.MyForm extend app.forms.MyForm. So whenever > a CBV declares its form is app.forms.MyForm, it would instead create an > instance of myapp.forms.MyForm. Same thing for the instanciation of the > views classes. > After thatn it gets a bit trickier for the manual instanciation you > could find in FormView.get_form() for example. But I'm not fully aware > of Python's possibilities regarding such a functionality. As the mocking > library allows to replace a class with another on the fly, I'm pretty > sure it can be done, but I have no idea at what expense that would be > and what the side effects could be. > > Anyway, I fully agree that there's something to do about it, as the ways > to do it by now are not really obvious. > > Brice > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/56eb4ce1-b0d5-443c-bd6a-c230fc41c6b5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
