I've put together a brief proof of concept here: https://github.com/seddonym/formsignals
It demonstrates what you could do with post_init, post_clean and post_save signals, which I've also implemented in a fork of Django (no test coverage or documentation yet though). The concept it demonstrates is two apps, a blog app and a priority app. The priority app is a pluggable app, unknown to the blog app, that allows users to mark blog entries as 'priority', providing they also put the word "Priority" in the title. (Bizarre example but I wanted to demonstrate why you might want to use post_clean.) The main place to look is in the receivers file here: https://github.com/seddonym/formsignals/blob/master/formsignals/priority/receivers.py I don't think this is a nice as subclassing the form in the first place, but that's not an option unless the maintainer of the blog app has exposed a way of hooking into it. As you can see you get a fair amount of power to encapsulate different logic between apps with very little code. I think the use cases for pre_init, pre_clean and pre_save are more niche, but it probably makes sense to include them for completeness. Would value any comments! On Monday, 6 March 2017 19:08:29 UTC, David Seddon wrote: > > Hi all, > > One thing I've always found challenging with Django is to adjust the > functionality of forms from other apps. An example might be to add an > extra field to a login form provided by a third party module. > > What I end up doing is often overriding the urlconf, view and form class. > Or, worse, monkey patching the form class. > > A much nicer way to do this would be to add a few well chosen signals to > forms. > > Potential ones could be: > > - post_init > - post_clean > - post_save (for ModelForms) > > I'd be happy to do a pull request for this, but just wondered what people > think. > > David > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/eb1dd68c-7006-4141-bace-045b87562f18%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
