Le livre de

Paramètres par défaut

Un fichier de paramètres Django n’a pas besoin de définir de paramètres si ce n’est pas nécessaire. Chaque paramètre possède une valeur par défaut. Ces valeurs par défaut se trouvent dans le fichier django/conf/global_settings.py.

Voici l’algorithme utilisé par Django lors de la compilation des paramètres:

• Chragement des paramètres depuis global_settings.py.
• chargement des paramètres depuis le fichier de configuration spécifié, écrasant les paramètres globaux si nécessaire.

Notez qu’un fichier de configuration ne doit pas faire d’import depuis global_settings, parce que cela est redondant.

Voir les paramètres que vous avez modifié

Il existe un moyen simple de voir lequel de vos paramètres dérivent des valeurs par défaut. La commande manage.py diffsettings affiche les différences entre les paramètres du fichier courant et ceux de Django par défaut.

manage.py est décrite plus en détail dans l’annexe G.

Utiliser les parmaètres dans le code Python

Dans vos applications Django, utilisez les paramètres en important l’objet django.conf.settings, par exemple:

from django.conf import settings

if settings.DEBUG:
    # Do something

Notez que django.conf.settings n’est pas un module - c’est un objet. L’import individuel de paramètres n’est donc pas possible:

from django.conf.settings import DEBUG  # Ceci ne fonctionnera pas.

FIXME FUZZY Notez aussi que votre code ne doit pas faire d’import soit depuis global_settings soit depsui votre propre fichier de paramètres. django.conf.settings fait abstraction des concepts de paramètres par défaut et de paramètres spécifiques à un site; il présente une interface unique. Il découple aussi le code qui utilise les paramètres de l’endroit où se trouvent vos paramètres.

Modifier les paramètres lors de l’exécution

Vous ne devriez pas modifier les paramètres dans votre application lors de l’éxécution. Par exemple, ne faîtes pas ceci dans une vue:

from django.conf import settings

settings.DEBUG = True   # Ne faîtes pas cela !

L’unique endroit pour assigner des paramètres se trouve dans un fichier de paramètres.

Sécurité

Puisque un fichier de paramètrage contient des informations sensibles, tel que le mot de passe de la base de données, vous devriez tout faire pour limiter son accès. Par exemple, changez ses permissions de façon à ce que vous seul et votre utilisateur «serveur web» puissent le lire. Ceci est particuilèrement important dans un environnement où l’hébergement est mutualisé.

Créer vos propres paramètres

Rien ne vous empêche de créer vos propres paramètres, pour vos applications Django. Suivez simplement ces conventions:

• Utilisez des lettres capitales pour le nom des paramètres.
• Pour les paramètres qui sont des séquences, utilisez des tuples plutôt que des listes. Les paramètres doivent être considérés comme immuables et ne doivent pas être changés une fois définis. L’utilisation des tuples relfète cette sémantique.
• Ne réinventez pas un paramètre déjà existant.

L’utilitaire django-admin.py

Lorsque vous utilisez django-admin.py (voir l’annexe G), vous pouvez fixer la variable d’environnement une fois ou explicitement transmettre le module des paramètres à chaque fois que vous lancez l’utilitaire.

Voici un exemple utilisant le shell Bash d’Unix:

export DJANGO_SETTINGS_MODULE=mysite.settings
django-admin.py runserver

Voici un exemple utilisant la console Windows:

set DJANGO_SETTINGS_MODULE=mysite.settings
django-admin.py runserver

Utilisez l’argument de ligne de commande --settings pour préciser les paramètres manuellement:

django-admin.py runserver --settings=mysite.settings

L’utilitaire manage.py créé par startproject comme faisant partie du squelette fixe DJANGO_SETTINGS_MODULE automatiquement; consultez l’annexe G pour plus de détails sur manage.py.

Au sujet du serveur (mod_python)

Dans votre environnement serveu, vous devrez indiquer à Apache/mod_python quels fichier de paramètres utiliser. Faites le avec SetEnv:

<Location "/mysite/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</Location>

Pour plus d’information; lisez la documentation Django mod_python en ligne à l’adresse http://www.djangoproject.com/documentation/0.96/modpython/.

Paramètres personnalisés par défaut

Si vous désirez que des valeurs par défaut arrive d’un autre endroit que django.conf.global_settings, vous pouvez transmettre moduel ou une classe qui fourni les paramètres par défaut en tant qu’argument default_settings (ou en tant que premier argument positionnel) dans l’appel à configure().

Dans cet exemple, les paramètres par défaut sont extrait de myapp_defaults, et le paramètre DEBUG est fixé à True, quelque soit sa valeur dans myapp_defaults:

from django.conf import settings
from myapp import myapp_defaults

settings.configure(default_settings=myapp_defaults, DEBUG=True)

L’exemple suivant, qui utilise myapp_defaults comme argument postionnel, est équivalent:

settings.configure(myapp_defaults, DEBUG = True)

Normalement, vous n’aurez pas besoin d’outrepasser les paramètres par défaut de cette manière. Les options par défaut de Django sont suffisament maîtrisées pour que vous puissiez les utiliser sans dangers. Soyez conscient du fait que si vous transmettez un nouveau module par défaut, alors vous devez spécifier une valeur pour tous les paramètres possibles qui pourraient être utilisé dans ce code que vous importez. Consultez django.conf.settings.global_settings pour la liste complète.

Soit configure() ou soit DJANGO_SETTINGS_MODULE est requis

Si vous ne paramétrez pas la variable d’environnement DJANGO_SETTINGS_MODULE, vous devez appeler configure() à un moment donné avant d’utiliser du code qui lit les paramètres.

Si vous ne paramètrez pas DJANGO_SETTINGS_MODULE sans appeler configure(), Django lévera une exception EnvironmentError la première fois qu’un paramètre est accédé.

Si vous paramétrez DJANGO_SETTINGS_MODULE, accédez à quelques valeurs de paramètres, puis appelez configure(), Django lévera une EnvironmentError précisant que les paramètres ont déjà été configurés.

De même, c’est une erreur d’appeler configure() plus d’une fois, ou d’appeler configure() après qu’un paramètre ait été accédé.

Cela revient à: utiliser exactement soit configure() ou DJANGO_SETTINGS_MODULE. Pas les deux, et pas aucun non plus.

ABSOLUTE_URL_OVERRIDES

Par défaut: {} (dictionnaire vide)

C’est un dictionnaire mettant en correspondance les chaînes "app_label.model_name" avec les fonctions qui acceptent un objet modèle et retourne son URL. C’est une manière d’outrepasser les méthodes get_absolute_url() sur la base de chaque installation. Voici un exemple: FIXME methods on a per-installation basis.

ABSOLUTE_URL_OVERRIDES = {
    'blogs.weblog': lambda o: "/blogs/%s/" % o.slug,
    'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year,
    o.slug),
}

Notez que le nom du modèle utilisé dans ce paramètre doit être en bas de casse, quelque soit de la casse actuelle du nom du modèle de classe.

ADMIN_FOR

Par défaut: () (une liste vide)

Ce paramètre est utilisé pour les modules de paramètrages du site d’administration. Ce doit être un tuple des paramètres des modules (au format 'foo.bar.baz') pour lequel ce site est un admin.

Le site d’administration utilise ceci pour sa documentation automatiquement introspectée des modèles, des vues, et des balises de gabarit.

ADMIN_MEDIA_PREFIX

Par défaut: '/media/'

Ce paramètre est le préfixe de l’URL pour les médias d’admin: CSS, JavaScript, et images. Assurez vous d’utiliser un slash final;

ADMINS

Par défaut: () (un tuple vide)

C’est un tuple qui liste les personnes qui obtiennent des notifications d’erreurs de code. Lorsque DEBUG=False et qu’une vue lève une exception, Django leur enverra un courrier indiquant toutes les informations liées à l’exception. Chaque membre du tuple doit être un tuple de (Nom complet, adresse de courrier électronique), par exemple:

(('John', 'john@example.com'), ('Mary', 'mary@example.com'))

Notez que Django écrira à toutes ces personnes à chaque fois qu’une erreur arrive.

ALLOWED_INCLUDE_ROOTS

Par défaut: () (un tuple vide)

C’est un tuple de chaînes représentant les préfixes autorisés pour la balise de gabarit {% ssi%}. C’est une mesure de sécurité, de façon à ce que les auteurs de gabarit ne puissent avoir accès aux fichiers auquels ils n’ont pas droit.

Par exemple, si ALLOWED_INCLUDE_ROOTS est ('/home/html', '/var/www'), alors {% ssi /home/html/foo.txt %} fonctionnera, mais {% ssi /etc/passwd %} non.

APPEND_SLASH

Par défaut: True

Ce paramètre indique s’il faut ajouter un slash final aux URLs. Cela est utilisé uniquement si CommonMiddleware est installé (voir le chapitre 15). Consultez aussi PREPEND_WWW.

CACHE_BACKEND

Par défaut: 'simple://'

Le moteur de traitement du cache à utiliser (voir le chapitre 13).

CACHE_MIDDLEWARE_KEY_PREFIX

Par défaut: '' (une chaîne vide)

C’est la clef de préfixe du cache que le middleware de cache doit utiliser (voir le chapitre 13). FIXME

DATABASE_ENGINE

Par défaut: '' (une chaîne vide)

Ce paramètre indique quel est le moteur de base de données à utiliser: 'postgresql_psycopg2', 'postgresql', 'mysql', 'mysql_old' ou 'sqlite3'.

DATABASE_HOST

Par défaut: '' (une chaîne vide)

Ce paramètre indique quel est l’hôte à utiliser lors de la connection à la base de données. Une chaîne vide signifie localhost. Ceci n’est pas utilisé avec SQLite.

Si cette valeur commence par une barre oblique ('/') et que vous utilisez MySQL, MySQL se connectera via un socket Unix au socket spécifié:

DATABASE_HOST = '/var/run/mysql'

Si vous utilisez MySQL et que cette valeur ne commence pas par une barre oblique, alors cette valeur est supposée être l’hôte.

DATABASE_NAME

Par défaut: '' (une chaîne vide)

C’est le nom de la base de données à utiliser. Pour SQLite, il s’agit du chemin complet vers le fichier de base de données.

DATABASE_OPTIONS

Par défaut: {} (un dictionnaire vide)

Pour les paramètres additionels à utiliser lors de la connection à la base de données. Consultez le document du module de motorisation pour les mot-clef disponible.

DATABASE_PASSWORD

Par défaut: '' (une chaîne vide)

Ce paramètre est le mot de passe à utiliser lors de la connection à la base de données. Il n’est pas utilisé avec SQLite.

DATABASE_PORT

Par défaut: '' (une chaîne vide)

C’est le port à utiliser lors de la connection avec la base de données. Une chaîne vide signifie le port par défaut. Il n’est pas utilisé avec SQLite.

DATABASE_USER

Par défaut: '' (une chaîne vide)

Ce paramètre est le nom d’utilisateur à utiliser lors de la connection à la base de données. Il n’est pas utilisé avec SQLite.

DATE_FORMAT

Par défaut: 'N j, Y' (e.g., Feb. 4, 2003)

C’est le formatage par défaut àutiliser pour les champs date des pages d’administration de Django listant les changements - et, possiblement, par d’autres parties du système. Il accepte le même format que la balise now (voir l’annexe F, Talbeau F-2).

Voyez aussi DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT, et MONTH_DAY_FORMAT.

DATETIME_FORMAT

Par défaut: 'N j, Y, P' (e.g., Feb. 4, 2003, 4 p.m.)

C’est le formatage par défaut à utiliser pour les champs horodatés des pages d’administration de Django listant les changements - et, possiblement, par d’autres parties du système. Il accepte le même format que la balise now (voir l’annexe F, Talbeau F-2). Voir aussi DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT, and MONTH_DAY_FORMAT.

DEBUG

Par défaut: False

Ce paramètre est un Booléen qui permet d’activer ou non le mode debug.

Si vous définissez des paramètres personnalisés, django/views/debug.py possède une expression rationnelle HIDDEN_SETTINGS qui masquera de la vue DEBUG tout ce qui contient 'SECRET, PASSWORD, ou PROFANITIES'. Ceci permet aux utilisateurs non identifiés de remonter les rapports d’erreurs sans voir les paramètres sensibles (ou offensif).

Toutefois, notez qu’il reste toujours des sections de votre rapport d’erreur qui restent inappropriées à la consultation publique. Les chemins d’accès, les options de configuration et consort qui tous donnent aux attaquants des informations complémentaires au sujet de votre serveur. Ne jamais déplier un site avec DEBUG activé.

DEFAULT_CHARSET

Par défaut: 'utf-8'

C’est le jeu de caractères par défaut à utiliser pour tous les objets HttpResponse, si un type MIME n’est pas spécifié manuellement. Il s’utilise avec DEFAULT_CONTENT_TYPE pour construire le Content-Type de l’en-tête. Voyez l’annexe H pour en savoir plus au sujet des objets HttpResponse.

DEFAULT_CONTENT_TYPE

Par défaut: 'text/html'

C’est le type de contenu à utiliser pour tous les objets HttpResponse, si un type MIME n’est pas manuellement spécifié. Il es utilisé avec DEFAULT_CHARSET pour construire le Content-Type de l’en-tête. Voyez l’annexe H pour en savoir plus au sujet des objets HttpResponse.

DEFAULT_FROM_EMAIL

Par défaut: 'webmaster@localhost'

C’est l’adresse de courrier par défaut à utiliser pour les diverses correspondances automatisées de ou des administrateur(s) du site.

DISALLOWED_USER_AGENTS

Par défaut: () (empty tuple)

C’est une liste d’objets «expression rationnelle» compilés représentant les chaînes de l’agent utilisateur qui ne sont pas autorisées à consultez les pages, sur tout le système. Utilisez ceci pour les mauvais robots/fureteurs. Ceci est utilisé uniquement si le CommonMiddleware est installé (voir le chapitre 15).

EMAIL_HOST

Par défaut: 'localhost'

C’est l’hôte à utiliser pour envoyer des courrièls. Consultez aussi EMAIL_PORT.

EMAIL_HOST_PASSWORD

Par défaut: '' (une chaîne vide)

C’est le mot de passe à utiliser pour le serveur SMTP défini dans EMAIL_HOST. Ce paramètre est utilisé en conjonction de EMAIL_HOST_USER lors de l’identification auprès du serveur SMTP. Si ‘lun de ces paramètres est vide, Django ne tentera pas de s’identifier.

Voir aussi EMAIL_HOST_USER.

EMAIL_HOST_USER

Par défaut: '' (une chaîne vide)

C’est le nom d’utilisateur à utliser pour le serveur SMTP server défini dans EMAIL_HOST. S’il est vide, Django ne tentera pas de s’identifier. Voir aussi EMAIL_HOST_PASSWORD.

EMAIL_PORT

Par défaut: 25

C’esdt le port à utiliser pour le serveur SMTP défini dans``EMAIL_HOST``.

EMAIL_SUBJECT_PREFIX

Par défaut: '[Django] '

C’est le préfixe de la ligne «sujet» des messages électroniques envoyés avec django.core.mail.mail_admins ou django.core.mail.mail_managers. Vous voudrez probablement vouloir inclure l’espace finale.

FIXTURE_DIRS

Par défaut: () (un tuple vide)

C’est une liste d’emplacements des fichiers de données accessoires, dans l’ordre de recherche. Notez que ces chemins d’accès doivent utiliser le style Unix pour les barres obliques avant, même sous Windows. Il est utilisé par le framework de test de Django, qui est abordé en ligne à l’adresse http://www.djangoproject.com/documentation/0.96/testing/.

IGNORABLE_404_ENDS

Par défaut: ('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi', 'favicon.ico', '.php')

Voir aussi IGNORABLE_404_STARTS et Rapport d'erreur par courrièl.

IGNORABLE_404_STARTS

Par défaut: ('/cgi-bin/', '/_vti_bin', '/_vti_inf')

C’est un tuple de chaînes qui spécifient le début des URLs devant être ignorés pour l’envoi de courrièls en cas de 404. Voir aussi SEND_BROKEN_LINK_EMAILS et IGNORABLE_404_ENDS.

INSTALLED_APPS

Par défaut: () (un tuple vide)

Un tuple de chaînes désignants toutes les applications qui sont activé dans cette installation Django. Chaque chaîne doit être un chemin Python complet vers un paquet Python contenant une application Django. Lisez le chapitre 5 pour en savoir plus au sujet des applications.

INTERNAL_IPS

Par défaut: () (un tuple vide)

Un tuple d’adresses IP, sous forme de chaînes, qui

• voit les commentaires de débugage, lorsque DEBUG est à True,
• Reçoit les en-têtes X si le XViewMiddleware est installé (voir le chapitre 15).

JING_PATH

Par défaut: '/usr/bin/jing'

C’est le chemin vers l’executable Jing. Jing est un validator RELAX NG , et Django l’utilise pour valider chaque XMLField de vos modèles. Voir http://www.thaiopensource.com/relaxng/jing.html.

LANGUAGE_CODE

Par défaut: 'en-us'

C’est une chaîne représentant le code de langue de cette installation. Elle doit être au format standard de langue - par exemple, U.S. English vaut "en- us". Voir le chapitre 18.

LANGUAGES

Par défaut: un tuple de toutes les langues disponibles. Cette liste grandi continuellement et toute copie incluse ici deviendra inévitablement obsolète sous peu. Vous pouvez voir la liste actuelle des langues traduites en regardant dans django/conf/global_settings.py.

La liste est un tuple formé de deux tuples au format (code de la langue, nom de la langue) - par exemple, ('ja', 'Japanese'). Ceci précise quelles sont les langues disponibles dans le choix des langues. Voyez le chapitre 18 pour plus de détails sur la sélection des langues.

Généralement, la valeur par défaut doit suffire. Paramétrez cela si vous voulez restreindre la selection des langues à une sous partie des langues fournit par Django.

Si vous définissez un paramètre LANGUAGES personnalisé, il est possible de marquer les langues sous forme de chaîne de traduction, mais vous ne devez jamais importer django.utils.translation depuis votre fichier de paramètres, puisque le module lui même dépends des paramètres, et cela pourrait aboutir à un import circulaire.

La solution est d’utiliser une fonction gettext() «factice». Voici un fichier de paramètres en exemple:

gettext = lambda s: s

LANGUAGES = (
    ('de', gettext('German')),
    ('en', gettext('English')),
)

Avec cet arrangement, make-messages.py continuera à trouver et à marquer ces chaînes pour la traduction, mais celle-ci ne s’effectuera pas à l’exécution - vous aurez donc à vous souvenir d’emballer les langues dans de réelles gettext() dans tout code utilisant LANGUAGES à l’exécution.

MANAGERS

Par défaut: () (un tuple vide)

Ce tuple est au même format que ADMINS qui spécifie qui doit recevoir des notifications de liens brisés lorsque SEND_BROKEN_LINK_EMAILS=True.

MEDIA_ROOT

Par défaut: '' (une chaîne vide)

C’est un chemin absolu vers le répertoire qui contient les médias pour cette installation (par exemple, "/home/media/media.lawrence.com/"). Voir aussi MEDIA_URL.

MEDIA_URL

Par défaut: '' (une chaîne vide)

Cet URL gère les médias servis depuis MEDIA_ROOT (par exemple, "http://media.lawrence.com").

Notez qu’il doit y avoir une barre oblique finale s’il s’agit d’un composant du chemin:

• Correct: "http://www.example.com/static/"
• Incorrect: "http://www.example.com/static"

MIDDLEWARE_CLASSES

Par défaut:

::(“django.contrib.sessions.middleware.SessionMiddleware”,

“django.contrib.auth.middleware.AuthenticationMiddleware”, “django.middleware.common.CommonMiddleware”, “django.middleware.doc.XViewMiddleware”)

C’est un tuple des classes de middleware à utiliser. Voir le chapitre 15.

MONTH_DAY_FORMAT

Par défaut: 'F j'

C’est le formatage par défaut à utiliser pour les champs date des pages d’administration Django listant les changements - et, possiblement, par d’autre partie du système - dans les cas où seul le mois et le jour sont affiché. Il accepte le même format que la balise now (voir l’annexe F, Tableau F-2).

Par exemple, lorsqu’une telle page est filtré selon une date, l’en-tête pour un jour donnée affiche le jour et le mois. Des localisations différentes ont des formats différents. Par exemple, L’anglais américain affichera «January 1», alors que l’espagnol utilisera «1 Enero». Voir aussi DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, et YEAR_MONTH_FORMAT.

PREPEND_WWW

Par défaut: False

Ce parmaètre indique s’il faut préfixer d’un sous domaine «www.» les URLs qui n’en n’ont pas. Ceci est utilisable seulement si CommonMiddleware est installé (voir le chapitre 15). Voir aussi APPEND_SLASH.

PROFANITIES_LIST

C’est un tuple de «profanities» (the quality or state of being profane, paramètres initiaux ? FIXME) , sous forme de chaînes, qui déclenchent une erreur de validation lorsque le validateur hasNoProfanities est appelé.

Nous ne listons pas ici les valeurs par défaut, puisque cela pourrait revenir à se charger le classement de la MPAA (ndt: Motion Picture Association of America, association interprofessionnelle qui défend les intérêts de l’industrie cinématographique américaine sur le territoire des États-Unis) sur le dos. Pour voir ces valeurs par défaut, consutlez le fichier django/conf/global_settings.py.

ROOT_URLCONF

Par défaut: Not defined

C’est une chaîne représentant le chemin complet d’importation de Python vers votre URLConf racine (par exemple, "mydjangoapps.urls"). Voir le chapitre 3.

SECRET_KEY

Par défaut: (Generated automatically when you start a project)

C’est une clef secrète particulière à cette installation de DJango. Elle est utilisé pour fournir un point de départ aux algorithmes de hachage des clefs secrètes. Initialisez là avec une chaîne aléatoire - au plus long au mieux. django-admin.py startproject en crée une automatiquement et la plupart du temps vous n’aurez pas besoin de la modifier.

SEND_BROKEN_LINK_EMAILS

Par défaut: False

Ce paramètre indique s’il faut envoyer un courrièl au(x) MANAGERS à chaque fois que quelqu’un récupère une page d’erreur 404 malgré une référence externe existante (c’est à dire, un lien brisé). Ceci est utilisable uniquement si CommonMiddleware est installé (voir le chapitre 15). Voir aussi IGNORABLE_404_STARTS et IGNORABLE_404_ENDS.

SERIALIZATION_MODULES

Par défaut: Not defined.

La sérialisation est une fonctionnalité qui reste sous intense développement. Consultez la documentation en ligne à l’adresse http://www.djangoproject.com/documentation/0.96/serialization/ pour plus d’information.

SERVER_EMAIL

Par défaut: 'root@localhost'

C’est l’adresse de messagerie d’où proviennent les erreurs, telles que celles envoyées à ADMINS et MANAGERS.

SESSION_COOKIE_AGE

Par défaut: 1209600 (two weeks, in seconds)

C’est l’âge des cookies de session, en secondes. Voir le chapitre 12.

SESSION_COOKIE_DOMAIN

Par défaut: None

C’est le domaine à utiliser pour les cookies de session. Initialisez le avec une chaîne telle que ".lawrence.com" pour les cookies mutli-domaine, ou utilisez None pour un cookie de domaine standard for cross-domain cookies, or use None for a standard domain cookie. Voir le chapitre 12.

SESSION_COOKIE_NAME

Par défaut: 'sessionid'

C’est le nom du cookie à utiliser pour les sessions; il peut prendre pour valeur ce que vous voulez. Voir le chapitre 12.

SESSION_COOKIE_SECURE

Par défaut: False

Ce paramètre indique s’il faut utiliser un cookie sécurisé en guise de cookie de session. S’il est fixé à True, le cookie sera marqué comme «sûr», ce qui signifie que les navigateurs peuvent s’assurer que le cookie est transmis uniquement par le biais d’une connexion HTTPS. Voir le chapitre 12.

SESSION_EXPIRE_AT_BROWSER_CLOSE

Par défaut: False

Ce paramètre indique s’il faut achever la session lorsque l’utilisateur ferme son navigateur. Voir le chapitre 12.

SESSION_SAVE_EVERY_REQUEST

Par défaut: False

Ce paramètre indique s’il faut enregistrer les données de session à chaque requête. Voir le chapitre 12.

SITE_ID

Par défaut: Not defined

C’est l’ID, sous forme d’entier, du site courant dans la table django_site de la base de donnéesas. Il est utilisé de façon à ce que les données de l’application puissent se greffer à des sites en particulier et qu’une seule base de données puisse gérer le contenu de plusieurs sites. Voir le chapitre 14.

TEMPLATE_CONTEXT_PROCESSORS

Par défaut:

("django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n")

C’est un tuple de «callables» qui sont utilisé pour peupler le contexte de RequestContext. Ces «callables» prennent un objet requête pour argument et retournent un dictionnaire d’éléments à injecter dans le contexte. Voir le chapitre 10.

TEMPLATE_DEBUG

Par défaut: False

Ce Booléen gère le mode de débuguage des gabarits. S’il est à True, la page d’erreur fantaisie affichera un rapport détaillé pour toute TemplateSyntaxError. Ce rapport contient les extraits significatifs de votre gabarit, avec les lignes appropriées mises en valeur.

Notez que Django affiche des pages d’erreur fantaisies seulement si DEBUG est à True, vous devrez donc fixer cela pour tirer partie de ce paramètre.

Voir aussi DEBUG.

TEMPLATE_DIRS

Par défaut: () (un tuple vide)

C’est une liste d’emplacements pour les sources des fichiers de gabarit, dans l’ordre de recherche. Notez que ces chemins doivent utiliser le style Unix pour les barres obliques, même sous Windows. Voir les chapitres 4 et 10.

TEMPLATE_LOADERS

Par défaut: ('django.template.loaders.filesystem.load_template_source',)

C’est un tuple de «callables» (sous forme de chaîne) qui savent comment importer les gabarits depuis des sources diverses. Voir le chapitre 10.

TEMPLATE_STRING_IF_INVALID

Par défaut: '' (Empty string)

C’est la sortie, sous forme de chaîne, que le système de gabarit doit utliser pour les variables qui ne sont pas valides (par exemple, mal orthographiées). Voir le chapitre 10.

TEST_RUNNER

Par défaut: 'django.test.simple.run_tests'

C’est le nom de la méthode à utiliser pour commencer à utiliser la suite de test. Elle est utilisé par le framework de test de Django, qui est abordé en ligne à l’adresse http://www.djangoproject.com/documentation/0.96/testing/.

TEST_DATABASE_NAME

Par défaut: None

C’est le nom de la base de données à utiliser lorsque l’on utilise la suite de test. Si la valeur None est précisée, la base de données de test utilisera le nom 'test_' + settings.DATABASE_NAME. Consultez la documentation du framework de test de Django, qui est détaillé en ligne à l’adresse http://www.djangoproject.com/documentation/0.96/testing/.

TIME_FORMAT

Par défaut: 'P' (e.g., 4 p.m.)

C’est le formattage par défaut à utiliser pour les champs de date des pages d’administration des listes de changement sous Django - et, potentiellement, par d’autres parties du système. Il accepte le même format que la balise now (voir l’annexe F, Tableau F-2).

Voir aussi DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT, et MONTH_DAY_FORMAT.

TIME_ZONE

Par défaut: 'America/Chicago'

C’est une chaîne représentant la zone horaire de cette installation. Les zones horaires sont au format Unix standard zic. Une liste relativement complète des chaînes de zones horaires peut être consultée à l’adresse http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE.

C’est la zone horaire en laquelle Django convertira toutes les dates/heures - qui n’est pas nécessairement la zone horaire du serveur. Par exemple, un serveur peut servir de multiples sites motorisé par Django, chacun ayant un paramètre de zone horaire propre.

Normallement, Django fixe la variable os.environ['TZ'] selon la zone horaire que vous avez spécifié dans le paramètre TIME_ZONE. Ainsi, toutes vos vues et tous vos modèles opérerons automatiquement dans la zone horaire correcte. Cependant, si vous utilisez la configuration manuelle des paramètres (décrit dans la section intitulée «Utilisation des paramètres sans le paramètre DJANGO_SETTINGS_MODULE»), Django ne touchera pas à la variable d’environnement TZ, et il vous reviendra de vous assurer que les processus tournent dans l’environnement correct.

URL_VALIDATOR_USER_AGENT

Par défaut: Django/<version> (http://www.djangoproject.com/)

C’est la chaîne par défaut à utiliser en tant qu’en-tête du User-Agent lorsqu’il vérifie que l’URL existe (voir l’option verify_exists de URLField; voir l’annexe B).

USE_ETAGS

Par défaut: False

Ce Booléen spécifie s’il faut retourner l’en-tête ETag. Cela épargne la bande passante mais ralenti les performances. Ceci est utilisé uniquement si CommonMiddleware est installé (voir le chapitre 15).

USE_I18N

Par défaut: True

Ce Booléen précise si le système d’internationalisation de Django (voir le chapitre 18) doit être activé. Il fournit une manière simple de désactiver l’internationalisation, pour des raisons de performances. S’il est fixé à False, Django fera quelques optimisations de façon à ne pas charger toute la machinerie d’internationalisation.

YEAR_MONTH_FORMAT

Defaut: 'F Y'

C’est le formattage par défaut à utiliser pour les champs de date des pages listant les changements dans l’inteface d’administration de Django - et potentiellement, dans les autres parties du système - pour les cas où seuls l’année et le mois sont affichés. Accepte le même format que la balise now (voir l’annexe F).

Par exemple, lorsqu’une page d’administration affichant la liste des changements est filtrée en profondeur sur une date, l’en-tête pour un mois donnée affiche le mois et l’année. Des localisations différentes ont des formats différents. Par exemple, l’anglais Américain utilisera «January 2006», alors qu’une autre localisation utilisera «2006/January».

Consultez aussi DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, et MONTH_DAY_FORMAT.

<< précédent ◊ suivant >>