Hi David,

It's good to hear that you did significant research in this area (which I 
couldn't tell from your original email).

I get how this feature can come in handy and I won't stand in the way if it 
gets implemented.

Improving the guidance about when (not) to use signals in the process would be 
great.

-- 
Aymeric.



> On 7 Mar 2017, at 10:29, David Seddon <davidseddo...@gmail.com> wrote:
> 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-developers 
> <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
>  
> <https://groups.google.com/d/msgid/django-developers/56eb4ce1-b0d5-443c-bd6a-c230fc41c6b5%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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/26353977-6013-49DE-9A33-550D53E065CE%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to