We'll you can change the `default` form Field using `django.db.models.Field.formfield`.
But that is actually the thing I don't like I think this needs to go: https:// github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/ db/models/fields/__init__.py#L869-L905 But at the end, I don't have a particular pain with all that. You can easily write your own model form, that changes the behavior. If you feel like changing it, go ahead, but I would welcome a removing the cross dependency. > On Mar 9 2016, at 2:34 pm, James Pic <james...@gmail.com> wrote: > > Hi ! > > Currently, by default, django's ModelForm uses form fields which are known to be compatible for the modelfield. > > By "compatible", I mean that it works when the ModelForm calls: > > \- ModelField.value_from_object() to get the initial formfield value for the model's field, via model_to_dict: https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7 /django/forms/models.py#L101-L107 \- ModelField.save_form_data() to save the form field's value, via construct_instance and save_m2m: https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7 /django/forms/models.py#L47-L63 https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7 /django/forms/models.py#L427-L446 > > To get the form field that's compatible with both ModelField methods, it calls ModelField.formfield(), via fields_for_models, again in django.forms.models: https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7 /django/forms/models.py#L178 > > There's got to be somewhere to couple both the db field and the form fields, and that seems to be in model fields. Note that ModelForm is not in django.forms, but in django.forms.models. That module encapsulates all coupling between django.forms and django.db.models. Perhaps it would have been a bit more intuitive to have such a set of modules: django.db, django.forms, django.models, django.models_forms. That would be moving code around, but the code wouldn't change and the result would be the same - so I figured when I gave it a try ;) > > Anyway, I opened this topic because I thought it would be cool if we could change the **default** formfield that is generated by ModelForms. I know there are means to override the defaults, but that means a lot of boilerplate code to override the form class every where (views, admin, admin inlines ...). This feature is heavily used in DAL v2 but really has nothing to do in an autocomplete app. It would be nice if we could change the **default** formfields used by ModelForm, from it's current logic "known-to-be-compatible", to an enhanced logic "best for project". "Best for project" is defined by the INSTALLED_APPS and the configuration these apps have. It would be really cool to have these features in Django so that every app could benefit from it because it would make form configuration a lot more DRY. Currently in Django, even if a project defines its own ModelFormS with their overrides (for every model), or even a custom ModelFormMetaclass, users have to override everything in Django to use that. This proposal is about allowing to change defaults. > > I found two ways of achieving this, perhaps there are more: > > \- make ModelFormMetaclass more configurable (a PoC https://github.com/jpic/xmodelform/blob/7de16ca1826c1bee91d9a5b616b78d3dff357f a4/xmodelform/forms.py#L118-L170 ), but it's a bit more "fuzzy" to know if a form field is "compatible" (as defined above) with the model field, unless we permit form fields to override value_from_object() and save_form_data() which are currently in model fields. Note that save_form_data() can be called before or after form.save(), depending on wether it is a (many to many field, virtual field) or not ( https://github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7 /django/forms/models.py#L438 ). Also, we'd need a setting to allow a project to change what is the default modelform class or metaclass it would use in django factories. > > \- add instance attributes for model fields to override the currently hard coded defaults in formfield(). > > Unless we can get more of the community involved in this, is seems more sane to go for the second option. The risk of doing something wrong(tm) when changing hard coded defaults to attributes is None as far as I understand. > > Are there any better way to override **default** form fields generated for models at the project-level ? > > \-- You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic /django-developers/zG-JvS_opi4/unsubscribe. To unsubscribe from this group and all its topics, 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/CALC3Kae9vd2KY13nEaUjQV%3DYxP- aVNVY3DRBYPPgheF9u_81CQ%40mail.gmail.com. For more options, visit 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/4q5uvzu4or2wakd3rvcqnm7l8-0%40mailer.nylas.com. For more options, visit https://groups.google.com/d/optout.
