Server-side Datatables are Form-like classes that are responsible for processing ajax queries from the client. A Datatable is referenced by a view, and the view initializes the Datatable with the original queryset. The Datatable is responsible for filtering and sorting the results, and the final object list is handed back to the view for serialization.

A Datatable, like a ModelForm, should contain an inner Meta class that can declare various options for importing model fields as columns, setting the verbose names, etc.



Legacy support Datatables



Meta class and options

class Meta

The model class represented by the table.

Default:All local non-relationship model fields.

The list of local model fields to be imported from the base model. The appropriate Column will be generated for each. Relationship-spanning ORM paths should not be used here, nor any “virtual” data getter like a method or property. For those, you should instead declare an explicit column on the Datatable with a name of your choosing, and set the sources accordingly.


A list of model field names to exclude if columns is not given.


The identifier for caching strategy to use on the object_list sent to the datatable. See Caching for more information.

Default:The model ‘s Meta.ordering option.

A list that controls the default table sorting, giving column names in the order of their sort priority. When a Column name is given instead of a model field name, that column’s sources list will be looked up for any sortable fields it references.

As with model ordering, using a - prefix in front of a name will reverse the order.


The default page length for response results. This can be changed by the user, and is ultimately in the hands of the client-side JS to configure.


A list of extra query paths to use when performing searches. This is useful to reveal results that for data points that might not be in the table, but which the user might intuitively expect a match.


A list of model fields from columns that should not be sortable when their Column instances are created. Explicitly declared columns should send sortable=False instead of listing the column here.


A list of column names that will be transmitted during ajax requests, but which the client should hide from the table by default. Using this setting does not enhance performance. It is purely for datatable export modes to use as a hint.


The template that will be rendered when the Datatable instance is coerced to a string (when the datatable is printed out in a template). The template serves as the starting point for the client-side javascript to initialize.

The default template creates <th> headers that have a data-name attribute that is the slug of the column name for easy CSS targeting, and the default search and sort options that the datatableview.js initializer will read to build initialization options.


Controls the existence of a <tfoot> element in the table. If True, the default structure_template will render another set of <th> elements with appropriate labels.

This is particularly useful when setting up something like per-column searching, which officially leverages the table footer, replacing each simple footer text label with a search box that applies only to that column’s content.


A helper setting that names a CSS id that the datatableview.js initializer will configure to hold a total result counter. This is strictly in addition to the normal readout that appears under a datatable. If you don’t want any such external result display, you can ignore this setting.


A dict of model field names from columns that should have their verbose_name setting overridden for the table header.

Example:labels = {'name': "Headline"}
processors = None

A dict of model field names from columns that need to declare a processor callback. The mapped values may be direct references to callables, or strings that name a method on the Datatable or view.

Example:processors = {'name': 'get_name_data'}