Introduction The model reference documentation explains how to use Django’s standard field classes – CharField, DateField, etc. For many purposes, those classes are all you’ll need. Sometimes, though, the Django version won’t meet your precise requirements, or you’ll want to use a field that is entirely different from those shipped with Django. Django’s built-in field types don’t cover every possible database column type – only the common types, such as VARCHAR and INTEGER. For more obscure col

See also The testing tutorial, the testing tools reference, and the advanced testing topics. This document is split into two primary sections. First, we explain how to write tests with Django. Then, we explain how to run them. Writing tests Django’s unit tests use a Python standard library module: unittest. This module defines tests using a class-based approach. Here is an example which subclasses from django.test.TestCase, which is a subclass of unittest.TestCase that runs each test inside a

About this document This document provides an introduction to the basics of web forms and how they are handled in Django. For a more detailed look at specific areas of the forms API, see The Forms API, Form fields, and Form and field validation. Unless you’re planning to build websites and applications that do nothing but publish content, and don’t accept input from your visitors, you’re going to need to understand and use forms. Django provides a range of tools and libraries to help you buil

static.serve(request, path, document_root, show_indexes=False) There may be files other than your project’s static assets that, for convenience, you’d like to have Django serve for you in local development. The serve() view can be used to serve any directory you give it. (This view is not hardened for production use and should be used only as a development aid; you should serve these files in production using a real front-end web server). The most likely example is user-uploaded content in M

set_language(request) [source] As a convenience, Django comes with a view, django.views.i18n.set_language(), that sets a user’s language preference and redirects to a given URL or, by default, back to the previous page. Activate this view by adding the following line to your URLconf: url(r'^i18n/', include('django.conf.urls.i18n')), (Note that this example makes the view available at /i18n/setlang/.) Warning Make sure that you don’t include the above URL within i18n_patterns() - it needs t

json_catalog(request, domain='djangojs', packages=None) [source] Deprecated since version 1.10: json_catalog() is deprecated in favor of JSONCatalog and will be removed in Django 2.0. In order to use another client-side library to handle translations, you may want to take advantage of the json_catalog() view. It’s similar to javascript_catalog() but returns a JSON response. The JSON object contains i18n formatting settings (those available for get_format), a plural rule (as a plural part o

class JSONCatalog [source] In order to use another client-side library to handle translations, you may want to take advantage of the JSONCatalog view. It’s similar to JavaScriptCatalog but returns a JSON response. See the documentation for JavaScriptCatalog to learn about possible values and use of the domain and packages attributes. The response format is as follows: { "catalog": { # Translations catalog }, "formats": { # Language formats for date, time, etc.

javascript_catalog(request, domain='djangojs', packages=None) [source] Deprecated since version 1.10: javascript_catalog() is deprecated in favor of JavaScriptCatalog and will be removed in Django 2.0. The main solution to these problems is the django.views.i18n.javascript_catalog() view, which sends out a JavaScript code library with functions that mimic the gettext interface, plus an array of translation strings. Those translation strings are taken from applications or Django core, accor

packages A list of application names among installed applications. Those apps should contain a locale directory. All those catalogs plus all catalogs found in LOCALE_PATHS (which are always included) are merged into one catalog. Defaults to None, which means that all available translations from all INSTALLED_APPS are provided in the JavaScript output. Example with default values: from django.views.i18n import JavaScriptCatalog urlpatterns = [ url(r'^jsi18n/$', JavaScriptCatalog.as_view(

domain Translation domain containing strings to add in the view output. Defaults to 'djangojs'.