djangodocs.org

654 sections in Django 4.2 Search all versions →

ModelFormMixin

Reference Editing mixins

classdjango.views.generic.edit.ModelFormMixin : A form mixin that works on ModelForms, rather than a standalone form.

Other methods

Reference The Django admin site ModelAdmin objectsModelAdmin methods

ModelAdmin.add_view(request,form_url='',extra_context=None) : Django view for the model instance addition page. See note below. ModelAdmin.change_view(request,object_id,form_url='',extra_context=None) : Django view for the model instance editing page. See note below. ModelAdmin.changelist_view(request,extra_context=None) : Django view for the model instances change list/actions page. See note below.

GeoDjango Forms API

Reference

GeoDjango provides some specialized form fields and widgets in order to visually display and edit geolocalized data on a map. By default, they use OpenLayers-powered maps, with a base WMS layer provided by NASA.

Field arguments

Reference GeoDjango Forms API

In addition to the regular form field arguments, GeoDjango form fields take the following optional arguments.

Output styles

Reference The Forms API Outputting forms as HTML

As well as rendering the form directly, such as in a template with {{ form }}, the following helper functions serve as a proxy to Form.render() passing a particular template_name value.

Subclassing forms

Reference The Forms API

If you have multiple Form classes that share fields, you can use subclassing to remove redundancy.

A full example

Topic guide Customizing authentication in Django Substituting a custom User model

class UserChangeForm(forms.ModelForm): """A form for updating users. Includes all the fields on the user, but replaces the password field with admin's disabled password hash display field.

Using mixins

Topic guide Introduction to class-based views

Mixins are a form of multiple inheritance where behaviors and attributes of multiple parent classes can be combined. For example, in the generic class-based views there is a mixin called TemplateResponseMixin whose primary purpose is to define the method render_to_response().

More on fields

Topic guide Working with forms More about Django Form classes

Consider a more useful form than our minimal example above, which we could use to implement “contact me” functionality on a personal website: forms.py Our earlier form used a single field, your_name, a CharField.

Basic file uploads

Topic guide File Uploads

Consider a form containing a FileField: forms.py A view handling this form will receive the file data in request.FILES, which is a dictionary containing a key for each FileField (or ImageField, or other FileField subclass) in the form.

Models

Reference System check framework Core system checks

models.E001: <swappable> is not of the form app_label.app_name. models.E002: <SETTING> references <model>, which has not been installed, or is abstract. models.E003: The model has two identical many-to-many relations through the intermediate model <app_label>.<model>.

Geometry Lookups

Reference GeoDjango Database API Spatial Lookups

Geographic queries with geometries take the following general form (assuming the Zipcode model used in the GeoDjango Model API): For example: In this case, poly is the geographic field, contains is the spatial lookup type, pnt is the parameter (which …

Widget attributes

Reference GeoDjango Forms API Form widgets

BaseGeometryWidget.geom_type : The OpenGIS geometry type, generally set by the form field. BaseGeometryWidget.map_height BaseGeometryWidget.map_width : Height and width of the widget map (default is 400x600). BaseGeometryWidget.map_srid : SRID code used by the map (default is 4326).

Widget classes

Reference GeoDjango Forms API Form widgets

OpenLayersWidget classOpenLayersWidget : This is the default widget used by all GeoDjango form fields. template_name is gis/openlayers.html. OSMWidget classOSMWidget : This widget uses an OpenStreetMap base layer to display geographic objects on. Attributes are:

Reference The Forms API Using forms to validate data

It’s meaningless to validate a form with no data, but, for the record, here’s what happens with unbound forms:

Outputting forms as HTML

Reference The Forms API

The second task of a Form object is to render itself as HTML. To do so, print it: If the form is bound to data, the HTML output will include that data appropriately.

Default rendering

Reference The Forms API Outputting forms as HTML

The default rendering when you print a form uses the following methods and attributes.

Specifying widgets

Reference Widgets

Whenever you specify a field on a form, Django will use a default widget that is appropriate to the type of data that is to be displayed.

BooleanField

Reference Model field reference Field types

classBooleanField(**options) A true/false field. The default form widget for this field is CheckboxInput, or NullBooleanSelect if null=True. The default value of BooleanField is None when Field.default isn’t defined.

Complex expressions

Reference Built-in template tags and filters Built-in tag referenceif

All of the above can be combined to form complex expressions. For such expressions, it can be important to know how the operators are grouped when the expression is evaluated - that is, the precedence rules.