Re: #26369: default formfield callback override
Hi Jamesie, I recently proposed adding a post_init signal for forms (https://groups.google.com/forum/#!topic/django-developers/SviNiWy3Bjc). Here's an example of how you might adjust the forms: https://github.com/seddonym/formsignals/blob/master/formsignals/priority/receivers.py If such a signal existed, I think you could use that to adjust widgets, fields etc. from a different app. You could even create a third party module which implemented a way of overriding this stuff using the settings you propose. If you think it might be useful, then it might be worth saying so on the forms signals feature thread? David On Sunday, 16 April 2017 23:18:13 UTC+1, Jamesie Pic wrote: > > Ooops yes this is correct, it doesn't work in the advised file, apps.py > > Thank you so much for your feedback, I need to ditch this patch just > find a way to make Django default usable date, time, image, relations > form fields useable ootb by marrying a JS framework. > > Best > <3 > -- 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/6d663725-55a8-4d9e-b0e2-a84b741ad65b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Feature idea: forms signals
Hi JP, That's a good point, sorry I didn't make it clear. The fork is installed from within the requirements file but you can also see it here, on the ticket_27923 branch: https://github.com/seddonym/django/tree/ticket_27923 I've updated the README to help. I'd be interested to hear if anyone thinks it's worth me making a pull request for this. David On Sunday, 16 April 2017 23:59:31 UTC+1, jp...@yourlabs.org wrote: > > Hello David, > > Is it possible to try to use it as part of the Django fork you mention, > instead of the app ? > > I couldn't find any link on your github profile, your website and google > but perhaps I've missed it. > > Thanks ! > > Best > <3 > -- 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/d4904940-91be-4f65-a16d-d39de1ffc382%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opportunity to contribute in Django
Hi Jainesh, Have a look at this page which should give you an idea about where to start: https://docs.djangoproject.com/en/1.10/intro/contributing/#finding-your-first-real-ticket On Monday, 13 March 2017 13:52:34 UTC, Jainesh Patel wrote: > > Hello, > > I am a final year CSE student from PICT, Pune, India. I am very interested > in contributing to Django. > > It would really be very helpful if you suggest any ideas to work on or any > bugs to resolve from where I can start. > > Hoping to hear from you soon, and thanking you in anticipation. > > Thank you, > Jainesh Patel > -- 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/3ade1a0b-8d30-44a8-99e6-f0da19dff8e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Feature idea: forms signals
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 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/eb1dd68c-7006-4141-bace-045b87562f18%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Feature idea: forms signals
I've created a ticket for this
here: https://code.djangoproject.com/ticket/27923#ticket
What are the next steps? Shall I create a pull request, or does this need
more consensus first?
David
On Wednesday, 8 March 2017 17:46:12 UTC, Melvyn Sopacua wrote:
>
> On Wednesday 08 March 2017 18:18:26 Melvyn Sopacua wrote:
>
> > On Monday 06 March 2017 10:10:41 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
>
> >
>
> > Putting in a +1 and use case for pre_init: Inject dynamically
>
> > generated form.prefix.
>
> >
>
> > Right now I have to inject PrefixedFormView in every view using it and
>
> > carefully watch my mro of already complex views.
>
> >
>
> > Use case is having several modals containing forms on a single page
>
> > ("Edit this", "Add related", "New this"). They need to be prefixed to
>
> > deal with naming conflicts since id_{fieldname} will not be page
>
> > unique anymore.
>
> >
>
> > With the signal, I can do away with the view mixin and the WrappedForm
>
> > is solely responsible for it.
>
> > I have no preference for the technology used (signal, hook, injection,
>
> > new buzzword), as long as the net result is that the object creating
>
> > the prefix can handle the prefix for all views.
>
> >
>
> > Is there a ticket yet?
>
> >
>
>
>
> Apologies for the formatting.
>
> https://gist.github.com/melvyn-sopacua/dbf3c8f71023d6fc261131cb0a851f58
>
>
>
>
>
> --
>
> Melvyn Sopacua
>
--
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/57a6f703-9498-450e-ab02-361651683c55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Feature idea: forms signals
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.
Feature idea: forms signals
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 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/d936a1d5-3f6e-4190-83c3-5cc31c8fbb4e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
