Questions about model form views

39 views

Skip to first unread message

Jerry Bash

unread,

Apr 13, 2016, 2:52:19 PM4/13/16

to Django users

Hello,

This is my first post on the list, I have only been using django for a short time, but have been impressed with it.

I obviously have a LOT to learn, and hope someone will be able to point me to the answer.

I'm aware that there are many ways to do something, but wonder it is best, or is there a more 'pythonic, django-esque' way.

I've recently started looking into using model form views.

Use of these model form views seems to streamline the development process further, but I'm wondering if you lose some flexibility.

https://docs.djangoproject.com/en/1.9/topics/class-based-views/generic-editing/#model-forms

and have a question about them.

Since these views "will automatically create a ModelForm,", is it still possible to specify a widget to use with specific fields in that form?

As in a 'manual' ModelFrom, ( https://docs.djangoproject.com/en/1.9/topics/forms/modelforms/#overriding-the-default-fields)

one can specify a widget, overriding the default.

Thanks,

Jerry

James Schneider

unread,

Apr 14, 2016, 4:56:12 AM4/14/16

to django...@googlegroups.com

> Since these views "will automatically create a ModelForm,", is it still possible to specify a widget to use with specific fields in that form?
>
> As in a 'manual' ModelFrom, ( https://docs.djangoproject.com/en/1.9/topics/forms/modelforms/#overriding-the-default-fields)
> one can specify a widget, overriding the default.
>

I'm a bit confused by your question given that the answer is the exact section in the aforementioned link.

Are you asking whether or not field attributes in a ModelForm can be altered via some magic within the CBV without manually specifying/defining a ModelForm class? If that's the case, then the answer is no as far as I know.

TL;DR; The view is for processing data and requests, forms are the data pathway and filter between the end-user (UI) and views. In general, views should not be concerned about how data is displayed.

The reason for this is to avoid mixing back-end/internal operations and UI design (in larger applications these can be controlled by different development teams). Django provides widget defaults and automatic ModelForms as a convenience to get things displaying quickly in templates and probably the admin portal, but many applications likely define custom Form or ModelForm classes anyway to provide other behaviors like custom validation.

The only exception I can think of would be to subclass an existing model field, override the default widget, and then use your new field in your model definition. Heck, doing that you could probably add in functionality to accept an extra keyword like widget= in the model field definition pretty easily to keep the subclass more general. I would only go that route if you have similar field/widget requirements for multiple models, though. Keep in mind that it will forcibly tie together your data structure and your UI, which usually causes more problems down the line. Then again, this whole paragraph is about modifying the model fields, not a change in the view, so apologies for going OT.

https://docs.djangoproject.com/en/1.9/howto/custom-model-fields/#specifying-the-form-field-for-a-model-field