grimboite/old/django-default-template.md

Title: Démarrer un projet Django Status: draft

Pour démarrer une application Django, on commence généralement par se créer un environnement virtuel (de préférences avec Python3), puis on installe les prérequis et on balance un petit django-admin startproject my_project.

Cette action construit une structure de type:

	my_project/             # le répertoire global
		my_project/         # le répertoire contenant les paramètres généraux (urls, settings, ...)
			settings.py     
			urls.py
			wsgi.py
		manage.py           # là où la magie de Django s'opère

Prérequis

Généralement, on placera les prérequis dans un fichier requirements.txt placé soit à la racine, soit dans un répertoire à part, et dans un format compréhensible par pip. L'intérêt est de pouvoir spécifier la ou les versions compatibles avec votre développementn et d'obliger à n'installer que cette ou ces versions-là. On pourra par exemple trouver un fichier requirements-prod.txt ainsi qu'un fichier requirements-dev.txt dans lequel on trouverait également un ensemble de dépendances spécifiques (tests unitaires, outils de debug, ...). Il est possible de faire hériter un fichier d'un autre en y ajoutant le paramètre -r <fichier_original.txt>:

# requirements-prod.txt
django<1.9
django-extensions

# requirements-dev.txt
-r requirements-prod.txt
django-debug-toolbar

Les paramètres principaux du projet sont placés dans le fichier settings.py. Ces paramètres reprennent par exemple les informations suivantes:

• Une secret_key (qui n'a, a priori, strictement rien à faire dans ce fichier!)
• La liste des applications installées
• La liste des middlewares activés
• Un paramètre ROOT_URLCONF pour que Django sache où trouver les routes
• La liste des templates disponibles (ou, au moins, où les trouver)
• Les bases de données
• La langue de l'application
• La time zone
• ...

Une bonne pratique consiste à créer un fichier local_settings dans lequel on déplacera le contenu du fichier settings. De cette manière, le contenu invariant se trouvera dans un fichier à part, et le fichier settings contiendra la configuration propre au déploiement du projet. Il suffit alors de démarrer notre fichier settings par la suite suivante: from local_settings import *.

Les applications

Une application dans Django représente un petit ensemble d'éléments liés à un même contexte. Pour de très petits projets, il est envisageable d'avoir une et une seule application, mais ce nombre peut très vite grandir. L'intérêt, c'est de pouvoir tester et gérer ce contexte de manière isolée. A terme, il peut surtout être intéressant d'exporter et de réutiliser cette application dans un autre projet.

Pour démarrer une nouvelle application, on lance la commande python manage.py startapp <app>. Une application vient avec quatre fichiers:

1. admin.py: le fichier dans lequel on va définir la manière dont l'application se comporte dans l'administration autogénérée de Django.
2. models.py: les classes telles qu'elles seront représentées dans la base de données. Comme Django vient avec son propre ORM, on se souciera peu de la base de données, et plus de la représentation logique des informations. En pratique, il est presque obligatoire de toujours tester les fonctionnalités sur la base de données de destination (PostgreSQL, SqlServer, MySQL, SQLite, ...)
3. tests.py: tout ce qui concerne les tests unitaires effectués sur l'application.
4. views.py: tout ce qui concerne l'affichage de vos données, les "vues" (équivalentes au contrôleur dans le pattern MVC)

Une fois ce schéma établi, rien ne vous empêche de créer des packages, de nouveaux modules, et de structurer votre projet ou votre application différement.

ORM

Après avoir créé quelques champs dans une classe, et quelques classes dans votre modèle, il est temps de faire le lien avec la base de données.

La configuration se passe toujours dans notre fichier settings: indiquez-y dans la variable DATABASES la clé default et le type de base que vous comptez utiliser. Par défaut, ceci est initialisé pour une base SQLite:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

Le fait de construire un dictionnaire permet de spécifier plusieurs bases de données, et donc plusieurs domaines d'applications. En utilisant un routeur, il est possible de définir quelle base est utilisée par une application, voire de définir une architecture type master-slave. Pour cela, le mieux est de voir directement dans la doc.

Migrations

Les migrations constituent un énorme avantage pour le développeur: tout le modèle est géré en Python et traduit en SQL. Il en va de même pour les modifications du modèle (suppression de champs, renommage, ...).

Dès qu'une application est gérée par Django, il suffit de lancer la migration avec la commande python manage.py makemigrations. Cela créera automatiquement les modifications nécessaires dans un fichier .py. Si le dossier migrations d'une application est manquant, aucune nouvelle migration ne sera créée.

Concrètement, un fichier de migration ressemble à ceci:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations

class Migration(migrations.Migration):

    dependencies = [
        ('todo', '0001_initial'),
    ]

    operations = [
        migrations.AddField(
            model_name='todo',
            name='priority',
            field=models.CharField(null=True, choices=[('A', 'Highest'), ('B', 'Medium'), ('C', 'Low')], max_length=1),
        ),
    ]

La migration hérite de la classe migrations.Migration et présente les champs dependencies (ie. les migrations qui doivent être appliquées avant celle-ci) et les opérations successives qui devront être jouées. Pour l'exemple ici, j'ai simplement ajouté un nouveau champ priority à la classe Todo. Et parmi les dépendances, il va falloir exécuter la migration 0001_initial de l'application todo auparavant.

Ce mode de fonctionnement permet de rejouer toutes les migrations sur un nouvel environnement.

Pour appliquer les migrations, lancez la commande python manage.py migrate.

Les fichiers statiques

Par défaut, le paramètre STATIC_URL est déjà initialisé. Il n'est cependant pas suffisant, puisqu'il ne fait qu'indiquer l'URL à laquelle les fichiers seront distribués, et pas leur emplacement physique sur le disque. Pour remédier à cela, il faut ajouter (comme indiqué dans la doc de Django):

STATICFILES_DIRS = (
    os.path.join(BASE_DIR, "static"),
    '/var/www/static/',
)