Re: #26369: default formfield callback override

[Jamesie Pic]

Hi David,

Yep, I'm with you on this, another good reason to close this PR. I'm
building DAL's next feature on your fork, so you'll have my feedback
for sure at some point ;)

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/CAC6Op18XCRC3Kj328OX0-0UqPMtwkQtu7O3p88Kgc%3De%3DGEHcdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[David Seddon]

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: #26369: default formfield callback override

[Jamesie Pic]

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/CAC6Op19jtK2EphhyeLL0NqBVg3JZ%3D%2Bbg8BScS9VwUVusx9Jh0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[Adam Johnson]

>
> About 1, if it's already working with a non-signal, how could it not work
> with a signal ? It is, after all, called from within formfield() in this
> implementation, so anything that's working today when formfield() is
> called, should work when formfield() emits a signal.
>

Signal handlers need to be registered before they get called. ModelForms
can be imported and thus instantiate their form fields by calling the model
fields' formfield() methods before your custom handler gets registered, so
they wouldn't be changed.

Btw another point for customization of forms would be the post_init form
signal as suggested here:
https://groups.google.com/forum/#!topic/django-developers/SviNiWy3Bjc

On 16 April 2017 at 10:58,  wrote:

> Hi Adam !
>
> About 1, if it's already working with a non-signal, how could it not work
> with a signal ? It is, after all, called from within formfield() in this
> implementation, so anything that's working today when formfield() is
> called, should work when formfield() emits a signal.
>
> For 2 & 3, yes, I know a lot of hacks exist. I just feel like I've been
> using them for the last decade, to every time replace the default field
> everywhere (forms, admin, drf, etc ...), it really looks like I'm fighting
> that I can't change the default myself.
>
> And this is systematically happening when I have a relation to another
> model, because the default widget does not work well when there is actual
> data in the relations, outside of the testing world where we have only a
> few instances.
>
> Am I really the only witness of this phenomenon ?
>
> <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/ee180045-fd08-45bd-aced-
> 4a674da80912%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM3S3vXBcaGQHkd--XNs7g1DGXhTLUdAyLB7pQ3j6JAPrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[Adam Johnson]

I've thought a bit more about this, and have had three ideas:

1. The signal idea doesn't seem likely to work in all cases due to import
order considerations. Forms can easily be imported during Django startup
whilst models, views, or urls, are imported, before AppConfig.ready() is
fired, which is the recommended point to register signals (docs
).
It would be surprising if this one particular signal needed registering at
some other point in time to work. Django currently has one signal which has
this property, class_prepared
 , but
it's also noted as not generally being used outside of Django's internals.

2. It is probably possible to use class_prepared at current to replace the
model fields on third party models with subclasses that define formfield()
to point at custom form fields.

3. It's definitely possible right now to modify form classes in existing
apps by modifying the fields on them after their construction with
something similar to the metaclass suggestion, like:

from otherapp.forms import FooForm

# We need to enforce our widgets on that form
FooForm.base_fields['html'] = fixup_field(FooForm.base_fields['html'])

On 23 December 2016 at 16:14, James Pic  wrote:

> Thanks for your reply Adam ! To make it general purpose, perhaps we could
> make such a patch in Django and replace should_fixup by a signal ?
>
> --
> 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/CALC3Kad0Y9ibX2Z9%2Bpj9mWCbc%
> 2B63zEBqAGC8K1eD47mgMKe5Vg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM1x_i8OBDXpz5sy4Sd-tiASDrRpV%3DrSFzjnwh2st13Bbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

Thanks for your reply Adam ! To make it general purpose, perhaps we could
make such a patch in Django and replace should_fixup by a signal ?

-- 
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/CALC3Kad0Y9ibX2Z9%2Bpj9mWCbc%2B63zEBqAGC8K1eD47mgMKe5Vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

Thanks a lot for your time and quick answer Adam ! The ModelFormMetaclass
usage you suggest is not supported by Django at this point. Suggesting that
doing it is easy and supported seems incorrect in my experience, starting
with the fact that there is no documentation.

There are a lot of problems out there with imaginary third party apps that
> you want to modify the internals of :)
>

I have to disagree here, it's perfectly supported to override the apps
views, forms and admins to change a widget: when it's done right it works.
It's just a lot of error-prone and manual work and I wish Django proposed a
way to reduce the cost of this.

In my experience, it works fine to enhance one app with the widget provided
by another. As demonstrated, it's already possible, but the cost of 6 steps
is something I'd like to reduce to one, DRY step.


> Often it's not hard to get third party apps to add some hook for extension
> (e.g. their own setting, or signal, ...) or to fork it yourself - easier
> than modifying Django core.
>

I don't understand why the community would be against reducing the cost of
using a form field or widget of an app to enhance another: given the number
of apps which provide just a form field or widget, I can hardly believe I'm
the only one to do this kind of things. I mean, are we formfield/widget app
maintainers so ahead time for maintaining such apps ?

I'm really sorry that I couldn't make it clear that we need a way to
"overriding the default form field generator ***mechanism***", and that
answers that were given to me are about just "overriding a form field",
similarly to the hundreds of StackOverflow answers and countless number of
blog posts I've published on this subject myself.

-- 
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/CALC3KacjBh8XO09cStzAvRbSCdcuJn8Wd-CWZp26LuejMFMrZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

Absolutely ! If we don't want to monkey patch, we can use the other step:
4. get control on the flatpage form in the admin:
https://gist.github.com/Kub-AT/3676137

Then, there's the fatpages use case. Fatpage is an imaginary fork of
flatpages that adds create and edit views. In this case, we also need the
following steps:

5. Subclass Fatpage views somewhere in our project so that it uses our forms

6. Override the create/edit urls to use our new views.

In the fatpages case, the proposal removes the cost of 1. 3. 4. 5. 6. and
cuts the cost of 2. by making it DRY-friendly.

About ModelFormMetaclass: are you suggesting to move the signal in
ModelFormMetaclass or do you have a lot more ambition ie. add new APIs ?

[0]
https://github.com/yourlabs/django-autocomplete-light/blob/v2/autocomplete_light/forms.py

[1] https://github.com/jpic/xmodelform/blob/master/README.rst

-- 
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/CALC3KadzmHZ44gosFYJYmtKbH9Y0vWCXx%2BNwARvNOkEfnq_dcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[Adam Johnson]

Oh, I misunderstood, I thought you controlled both the models and forms but 
wanted to enforce consistency. If you don't control the models (like 
FlatPage), I presume you control the forms then?You can do it then with a 
custom ModelForm subclass that overrides some of the building behaviour.

You'd have to subclass ModelFormMetaclass but it seems doable to me - you 
can customize the form class after ModelFormMetaclass has built it, by 
replacing any form fields that have been built with the ones you like.

On Thursday, December 22, 2016 at 3:27:31 PM UTC, is_null wrote:
>
> Thanks for your suggestion Adam ! However, I have a feeling that to apply 
> that technique on the flatpages use case we'd also have to:
>
> 4. Monkey patch django.contrib.models.FlatPage.content,
>
> 5. Override and deal with flatpages migrations from now on.
>
> The proposal removes the cost of steps 1., 3., 4. and 5 and cuts the cost 
> of step 2. replacing the change in multiple model files to a single change 
> at one place.
>
> I definitely agree that a signal would be a lot better than a callback 
> setting ;)
>
> === ERRATA
> There was an error in my previous email, this was actually the second 
> feature of the list:
> - allows to override default form fields or form field options without 
> touching their code.
> Should have been:
> - allows to override external app model default form fields or form field 
> options without touching their code.
>
>
>

-- 
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/5d32a3fe-7d6a-4584-b4c5-7ee0ed57d3f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[James Pic]

Thanks for your suggestion Adam ! However, I have a feeling that to apply
that technique on the flatpages use case we'd also have to:

4. Monkey patch django.contrib.models.FlatPage.content,

5. Override and deal with flatpages migrations from now on.

The proposal removes the cost of steps 1., 3., 4. and 5 and cuts the cost
of step 2. replacing the change in multiple model files to a single change
at one place.

I definitely agree that a signal would be a lot better than a callback
setting ;)

=== ERRATA
There was an error in my previous email, this was actually the second
feature of the list:
- allows to override default form fields or form field options without
touching their code.
Should have been:
- allows to override external app model default form fields or form field
options without touching their code.

-- 
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/CALC3Kad-ND9gBdn-zMTriM40b6YWyos34McCrHX1ncgLJ8UXjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[Tim Graham]

Hi,

It's not clear to me whether or not this proposal considers the concerns 
from the last time you raised the idea some months ago. Perhaps you could 
summarize that discussion so we don't rehash it.

Thanks. 

https://groups.google.com/d/topic/django-developers/zG-JvS_opi4/discussion

On Thursday, December 22, 2016 at 3:47:18 AM UTC-5, is_null wrote:
>
> Hi all,
>
> I'm looking for a way to override the default form field widget for some 
> fields of some model classes, at the project level.
>
> Currently, we have to override all the model classes for that. That's 
> considerable as a hack, because we don't exactly want to "override the 
> default in every form class" but we want to "override the default".
>
> The reason I need this at the project level is that really it's that 
> unique combination in INSTALLED_APPS that provides whatever widget I'd like 
> to override the default widget with, and how my project forms will look 
> like.
>
> For example, I'd like to have a RadioSelect for all relations to Foo 
> model and a django-redactor for all text fields named "html", my logic 
> looks like:
>
> if getattr(db_field, 'rel', None) and db_field.rel.to == Foo:
> defaults['widget'] = forms.RadioSelect
> if db_field.model == Bar and 'html' in db_field.name:
> defaults['widget'] = redactor.RedactorWidget
>
> A simple possibility is to add a setting which value would be a dotted 
> path to a callback, and basically change Field.formfield() so that it 
> would use this callback if it's defined. Here's an example patch: https://
> github.com/django/django/pull/7723
>
> Thanks for your feedback.
>

-- 
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/71325b52-ab53-4a5f-af4e-2a785f6e2490%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#26369: default formfield callback override

[James Pic]

Hi all,

I'm looking for a way to override the default form field widget for some
fields of some model classes, at the project level.

Currently, we have to override all the model classes for that. That's
considerable as a hack, because we don't exactly want to "override the
default in every form class" but we want to "override the default".

The reason I need this at the project level is that really it's that unique
combination in INSTALLED_APPS that provides whatever widget I'd like to
override the default widget with, and how my project forms will look like.

For example, I'd like to have a RadioSelect for all relations to Foo model
and a django-redactor for all text fields named "html", my logic looks like:

if getattr(db_field, 'rel', None) and db_field.rel.to == Foo:
defaults['widget'] = forms.RadioSelect
if db_field.model == Bar and 'html' in db_field.name:
defaults['widget'] = redactor.RedactorWidget

A simple possibility is to add a setting which value would be a dotted path
to a callback, and basically change Field.formfield() so that it would use
this callback if it's defined. Here's an example patch: https://github.com/
django/django/pull/7723

Thanks for your feedback.

-- 
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/CALC3Kacn1k01wW824r%3Dp5Dn87%3DfkfNLDxCZz_68x83HaBsjmeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.