1.1.1   Ses forces

• Mapping relationnel objet, grande API, efficace, remarqué par Guido van Rosum.
• Système de cache.
• Backoffice généré.
• Design des URL.
• Système de templates simple, complet et rapide.
• Modules de contributions étendant les fonctionnalités
• Documentation.
• Bonne communauté.
• Facilité d'apprentissage.
• Découpage intelligent des projets.
• Internationalisation
• Extensibilité
• Rapidité de développement
• Outils d'administration de bases de données
• Compatibilité WSCGI
• Philosophie DRY
• Robuste

1.1.2   Plus d'informations

• DjangoProject
• Django-fr

1.2.1   Vue d'ensemble

Couplage faible

Les différentes couches du framework ne devraient pas se connaître les unes les autres à moins que cela soit absolument nécessaire.

Moins de code

Les applications Django devraient utiliser aussi peu de code que possible; elles devraient rester agiles. Django devrait profiter pleinement des possibilités dynamiques de Python, tel que l'introspection.

Développement rapide

L'intérêt d'un framework du 21ème siècle est de rendre rapide les tâches fastidieuses du développement Web. Django devrait permettre un développement Web incroyablement rapide.

Ne vous répétez pas (Don't Repeat Yourself)

Chaque concept/portion de données distincts devrait résider en un, et un seul, endroit. La redondance est mal. La normalisation est bien.

Explicite est meilleur qu'implicite

Ceci, un principe au cœur de Python, veut dire que Django ne devrait pas faire de choses trop magiques. La magie ne devrait pas apparaître tant qu'il n'y a pas de raison valable pour cela. La magie vaut la peine d'être employée seulement si elle amène un grand confort, inaccessible d'une autre manière, et si elle n'est pas implémentée de manière à rendre confus les développeurs qui essayent d'apprendre à utiliser la fonctionnalité.

Cohérence

Le framework devrait être cohérent à tout niveau. La cohérence s'applique à tout élément depuis le bas niveau jusqu'au haut niveau.

1.2.2   Modèles

Inclure toute la logique appropriée

Les modèles devraient encapsuler chaque aspect d'un objet, selon le patron de conception Active Record de Martin Fowler. C'est pour cette raison que les options d'administration spécifiques au modèle sont incluses dans le modèle lui même; les données relatives au modèle devraient être stockées dans le modèle.

1.2.3   API de la base de données

Efficacité SQL

Elle devrait exécuter des requêtes SQL le moins souvent possible, et elle devrait optimiser les requêtes en interne.

Syntaxe succincte mais puissante

L'API de base de données devrait autoriser de riches et consistantes requêtes dans un minimum de syntaxe possible. Elle ne devrait pas s'appuyer sur l'import d'autres modules ou d'objets d'aide à la mise en forme. Les jointures devraient être réalisées automatiquement, en coulisse, lorsque nécessaire.

Une option pour exécuter une requête SQL facilement

L'API de base de données devrait réaliser qu'elle est un raccourci mais pas nécessairement un tout-en-un. Le framework devrait rendre facile l'écriture de SQL sur mesure -- des requêtes complètes, ou juste des clauses WHERE personnalisées en tant que paramètres pour les appels à l'API.

1.2.4   Conception des URLs

Couplage faible

Le système d'URL Django devrait permettre aux URLs provenant de la même application d'être différentes dans des contextes différents. Par exemple, un site peut mettre les articles à /articles/, alors qu'un autre peut utiliser /nouvelles/.

Flexibilité infinie

Les URLs devraient aussi flexibles que possible. Toute conception d'URL imaginable devrait être permise.

Encourager les bonnes pratiques

Le framework devrait faire en sorte qu'il soit facile (ou plus facile) pour un développeur de concevoir de jolies URLs que des mauvaises. Les extensions de fichier dans les URLs des pages Web devraient être évitées.

URLs permanentes

Techniquement, foo.com/bar et foo.com/bar/ sont deux URLs différentes, et les robots des moteurs de recherche (et quelques outils d'analyse du traffic) pourraient les traiter de manière séparée. Django devrait faire un effort pour "normaliser" les URLs afin ne pas permettre la confusion aux robots des moteurs de recherche.

1.2.5   Système de template

Séparer la logique de la présentation

Nous voyons un système de template comme un outil contrôlant la présentation et la logique relative à la présentation -- et c'est tout. Le système de template ne devrait pas supporter de fonctionnalités qui vont au delà de ces principes de base.

Décourager la redondance

L'héritage au sein des templates, permet de se passer de la duplication de certains éléments du contenu, tel le footer ou le header.

Etre dissocié du HTML

Le système de template ne devraient pas être conçu pour seulement produire du HTML. Il devrait être également bon à générer d'autres formats basés sur du texte, ou juste du texte.

Sûreté et sécurité

Le système de template, nativement, devrait interdire l'inclusion de code malicieux -- tel que des commandes supprimant les données en base.

Extensibilité

Le système de template devrait prendre en compte le fait que les auteurs de templates de niveau avancé peuvent vouloir étendre cette technologie. C'est le concept derrière les marqueurs et les filtres de template personnalisés.

1.2.6   Vues

Simplicité

L'écriture d'une vue devrait être aussi simple que d'écrire une fonction Python. Les développeurs ne devraient pas avoir besoin d'instancier une classe quand une fonction suffit.

Couplage faible

Une vue ne devrait pas se soucier du système de template que le développeur utilise -- ou même si un système de template est utilisé ou non.

Différencier entre GET et POST

GET et POST sont distincts; les développeurs devraient explicitement utiliser l'un ou l'autre. Le framework devrait facilement distinguer les données GET et POST.

1.3.1   Installation de Django

Pour cela il est nécessaire de télécharger le code source de Django. Nous allons nous baser sur la dernière version stable publiée, la 1.0

Dans un terminal exécutons ces commandes

$> wget http://www.djangoproject.com/download/1.0/tarball/
$> tar -xvzf Django-1.0.tar.gz
$> cd Django-1.0
$> sudo python setup.py install

1.3.2   Création du projet en local

Maintenant il est nécessaire de créer un répertoire qui stockera vos projets, comme cela les développements seront centralisés. Une fois dans ce répertoire, exécutez la commande suivante

$> django-admin.py startproject monprojet

Votre projet est désormais créé.

1.3.3   Qu'est ce qu'un projet Django

Au final qu'est ce qu'un projet Django ?

Si nous regardons le contenu du répertoire de notre projet, nous y retrouvons plusieurs choses :

__init__.py

Ce fichier permet de dire à l'interpréteur python que ce répertoire est un module python. C'est la norme.

manage.py

Script python reprenant les fonctionnalités de django-admin.py et qui servira aux tâches d'administration de notre projet

settings.py

Ce fichier va contenir toute la configuration de notre projet. Il sert de point d'entrée à notre projet. Ecrit en python, ce fichier de configuration est très souple à manipuler.

urls.py

Comme son nom l'indique, ce fichier contiendra les urls associées à notre projet. Il est le squelette du projet, faisant la liaison entre le code et les urls.

Au final nous pouvons donc dire qu'un projet Django est un module python permettant l'administration et le contrôle des différents composants intervenant dans le projet. Composants appelés Applications

1.4.1   Qu'est ce qu'une application

Une application est un simple module python. La meilleure preuve est de regarder le contenu du répertoire monapplication. Les fichiers suivants sont présents :

__init__.py

Ceci est le fichier qui prouve que le répertoire est un module python, car sa présence l'indique à l'interpréteur.

models.py

Module python contenant les classes python relatives aux models de l'application. Utiliser ce fichier pour écrire ses models est la norme.

views.py

Idem que pour models sauf qu'ici seront écrites les vues de l'application.

Une application Django est donc un simple module python définissant un ensemble de fonctions et de classes, qui seront utilisées au sein de notre projet.

1.4.2   Standalone versus Coupled applications

Il est important de savoir qu'il existe 2 manières de développer une application :

Coupled

Une application dite couplée est typiquement une application créée par la commande startapp au sein de notre projet. Elle va lier l'application avec notre projet, ce qui aura l'inconvénient de devoir spécifier précisément les chemins d'importation de l'application et d'en limiter grandement la réutilisabilité.

Dans le cas d'un développement spécifique, ceci ne pose pas de problème, mais il n'est recommandé de procéder ainsi.

Standalone

Une application Standalone est une application indépendante du projet, qui pourra résider n'importe où dans $PYTHON_PATH. Dans le cas d'une application réutilisable et/ou distribué, il est nécessaire de procéder ainsi.

Nous utiliserons cette méthode tout au long des travaux pratiques.

1.5.1   Qu'est ce qu'un model ?

Un model est un objet dans Django servant à interagir avec une base de données. Il doit contenir toutes les propriétés et méthodes de notre objet représenté. Un model pouvant avoir des relations avec d'autres models, ces relations devront êtres aussi décrites.

Les models serviront de structure à notre application, et en définiront une bonne partie de la logique.

C'est pour cette raison qu'il est nécessaire de commencer nos applications par une conception solide de nos models.

1.5.2   Notre première application

Pour se baser sur un exemple concret, nous allons créer une application de répertoire téléphonique.

Dans votre répertoire de développement tapez les commandes suivantes

$> mkdir repertoire_telephonique
$> touch repertoire_telephonique/__init__.py
$> touch repertoire_telephonique/models.py

Etant donné que cette application sera standalone il est nécessaire qu'elle soit accessible grâce à la variable d'environnement $PYTHON_PATH.

Pour cela, vous pouvez créer par exemple votre application dans un répertoire indiqué par $PYTHON_PATH

$> echo $PYTHON_PATH

Vous pouvez aussi modifier votre variable d'environnement en rajoutant votre répertoire de développement au $PYTHON_PATH.

Ou bien créer un lien symbolique depuis un répertoire accessible vers votre module.

1.5.3   Nos premiers models

Nous devons maintenant construire nos models qui vont donc définir la logique de notre application. Notre application sera constituée de 2 models, l'un représentant un contact et un autre représentant ses numéros de téléphones.

Editons le fichier repertoire_telephonique/models.py pour qu'il ressemble à cela :

>>> from django.db import models
>>>
>>> class Contact(models.Model):
>>>
>>>   first_name = models.CharField(max_length=50)

>>>   last_name = models.CharField(max_length=50)
>>>
>>>   def __unicode__(self):
>>>     return '%s %s' % (self.first_name, self.last_name)
>>>
>>>  class Phone(models.Model)
>>>
>>>     PHONE_CHOICES = (('pro', 'Professionel'),
>>>                      ('mobile', 'Mobile'),
>>>                      ('fixe', 'Fixe'))

>>>
>>>     contact = models.ForeignKey(Contact, null=True, blank=True)
>>>     type = models.CharField(max_length=10, choices=PHONE_CHOICES)
>>>     value = models.CharField(max_length=20)
>>>
>>>   def __unicode__(self):
>>>     return '%s %s : %s' % (self.contact, self.type, self.value)
>>>

1.5.4   Installation des models

Maintenant que nous possédons, nos propres models, il est nécessaire de les installer.

Installer les models d'une application, revient à installer l'application. Pour cela, il faut éditer les ficher settings.py de votre projet, et y rajouter 'repertoire_telephonique', dans la section INSTALLED_APPS

Maintenant nous allons établir une synchronisation entre les models et notre base de données. Cette synchronisation servira à créer les tables SQL décrites par vos models.

$> python manage.py syncdb

1.5.5   Ce que nous voyons

Les models écrits vont servir d'interface avec la base de données. Les attributs de classe définis au sein du model serviront de colonnes et définiront le type. Ce sont les Fields

Il existe des Fields pour à peut prêt chaque utilisation, il est même possible de créer ses propres Fields.

1.5.6   Manipulations des models

Il possible désormais d'utiliser les models comme interface avec notre base de données.

$> python manage.py dbshell

>>> from repertoire_telephonique.models import Contact, Phone

>>> Ccntact.objects.get_or_create(first_name='Julien', last_name='Fantomas')
>>> Contact.objects.all().count()
... 1

1.6.1   Exemples

Voici un exemple simple de vue en liste et detaillée:

>>> urlpatterns = patterns('django.views.generic.list_detail',
>>>                        url(r'^$', 'object_list',
>>>                            name='my_object_list'),
>>>                        url(r'^(?P<object_id>\d+)/$', 'object_detail',
>>>                            name='my_object_detail'),
>>>                        )

Ce qui donnera à l'utilisation dans votre navigateur :

http://www.votredomaine.com/
http://www.votredomaine.com/42/

1.7.1   Administration simple

Une des premières choses à effectuer est d'activer le module d'administration. Pour cela dans votre fichier settings.py de votre projet ajouter 'django.contrib.admin' à l'intérieur de la section INSTALLED_APPS.

Pour continuer son installation il est nécessaire d'associer une url aux vues du module d'administration. Le fichier urls.py situé dans votre projet contient déjà un exemple d'urls pour accéder à l'administration, mais il est commenté. Décommentez les lignes suivantes, pour avoir ceci :

>>> from django.contrib import admin
>>> admin.autodiscover()

>>> (r'^admin/(.*)', admin.site.root),

Ensuite exécutez la commande suivante, pour synchroniser les models contenus dans l'application admin afin d'en assurer son fonctionnement.

$> python manage.py syncdb

Désormais, si on lance le serveur de développement contenu dans Django, par la présente commande,

$> python manage.py runserver

on peut accéder à l'interface d'administration grâce à cette url :

http://localhost:8000/admin

Une fois identifié vous pouvez voir une liste des différentes applications installées sur le serveur et qui sont administrables.

Par contre, nous ne voyons pas notre application au sein de l'administration, ce qui est plutôt dommage, donc nous allons remédier à cela.

1.7.2   Administration de nos applications

Pour activer nos applications aux seins de l'administration c'est très simple, il suffit d'enregistrer nos models dans le module d'administration.

Pour cela nous allons créer un module admin.py au sein de notre application de répertoire téléphonique.

$> cd repertoire_telephonique/
$> touch admin.py

Editons le pour qu'il ressemble à cela :

>>> from django.contrib import admin
>>>
>>> from repertoire_telephonique.models import Contact
>>> from repertoire_telephonique.models import Phone
>>>
>>> admin.site.register(Contact)
>>> admin.site.register(Phone)

Désormais si on relance le serveur de développement, et que l'on recharge la page d'administration, nous y voyons apparaitre notre application avec ses tables prêtes à être administrées.

Le résultat est plus basique, mais il est possible d'aller plus loin dans la configuration de l'administration de nos models.

1.7.3   Administration évoluée

Pour atteindre un résultat où les vues d'administration soient efficaces et faciles à administrer, il est souvent nécessaire de les configurer. Il nous faut créer différentes classes définissant le comportement de chacun de nos models dans l'administration. Ajoutons ce code dans notre fichier admin.py.

>>> class ContactAdmin(admin.ModelAdmin):
>>>   list_display = ('first_name', 'last_name')
>>>

>>> admin.site.register(Contact, ContactAdmin)
>>>
>>> class PhoneAdmin(admin.ModelAdmin):
>>>   list_display = ('contact', 'type', 'value')
>>>
>>> admin.site.register(Phone, PhoneAdmin)

Nous avons juste modifié l'affichage de la vue en liste, mais il parait déjà plus efficace.

Désormais si on regarde la documentation du module d'administration nous voyons qu'il existe pleins de possibilités d'administration. Essayez un peu.

2.2.1   Configuration des urls

Pour utiliser les vues génériques, tout va se passer aux niveaux des urls. Dans notre répertoire de notre application npublisher nous allons créer un fichier nommé urls.py contenant ce code :

>>> """Urls of npublisher"""
>>>
>>> from django.conf.urls.defaults import *
>>>
>>> from npublisher.models import Entry
>>>
>>> entry_conf = {'queryset': Entry.objects.all()}

>>>
>>> urlpatterns = patterns('django.views.generic.list_detail',
>>>                        url(r'^$', 'object_list',
>>>                            entry_conf, 'npublisher_entry_list'),
>>>                        url(r'^(?P<slug>[-\w]+)/$', 'object_detail',
>>>                            entry_conf, 'npublisher_entry_detail'),
>>>                        )

A partir de là plusieurs choses sont à noter :

• Ce fichier d'urls peut être inclus dans le fichier d'urls de votre projet, grâce à la fonction include, par exemple :

  >>> (r'^informations/', include('npublisher.urls')),
  

• Désormais grâce au nommage des urls, il est possible d'avoir un couplage faible au niveau du models, tout en lui définissant une url absolue, utile elle aussi pour la notion de couplage faible. Seul le fichier urls.py de votre projet se maitre de chaque url utilisée dans votre projet, grâce à un mécanisme d'inversement. Utilisons cela sur notre model Entry et ajoutons cette méthode :

  >>> class Entry(models.Model):
  >>>  ...
  >>> @models.permalink
  
  >>> def get_absolute_url(self):
  >>>   return ('npublisher_entry_detail', (), {'slug': self.slug})
  

• Un seul fichier, peu de code, des urls réutilisables.

• queryset est le seul argument obligatoire pour ces vues, il

  définit de manière figée sur quelles instances du model il peut regarder.

2.3.1   Remarques

• Django possède plusieurs systèmes d'acquisition de templates, le premier étant celui qui va regarder dans la liste de dossiers définis dans la section TEMPLATE_DIRS de votre fichier settings.py. Un autre moyen est de vérifier dans le dossier de vos applications installées si un dossier templates existe pour l'inclure dans les recherches. C'est ici la technique utilisée.
• Grâce à ces différentes techniques d'acquisition, il est possible de modifier le rendu d'une application par défaut, en dupliquant le template visé pour le modifier et le mettre dans un chemin d'acquisition prioritaire.
• Il est donc aisé de fournir un jeu de templates à une application réutilisable, pour ensuite les remplacer en fonction des besoins de personnalisation.

2.3.2   Philosophie des templates

Un template, sert juste à mettre en forme des données. C'est pourquoi le système de template est tout aussi bien capable de produire du HTML, du CSV ou bien encore du PDF.

Les templates ne doivent pas incorporer trop de logique, sauf celle de la présentation, le reste doit être délégué aux vues ou aux models en eux mêmes.

Maintenant réalisons nos templates.

2.3.3   Centralisation et héritage dans les templates

Le système de template dans Django est assez puissant pour permettre l'héritage entre templates. Cette fonctionnalité évite la redondance de certains éléments communs à différents templates.

Dans le cas d'un site internet, ces éléments, seront les métas de publication, la navigation, le footer. Inutile de copier coller, ou d'inclure, il suffit d'hériter.

2.3.4   Technique à 3 niveaux

Il est possible de faire à peut prêt ce que l'on veut, avec le système de template, mais une technique robuste et souple au niveau de la personnalisation est retenue. Celle de la technique à 3 niveaux.

Dans la section TEMPLATE_DIRS du fichier settings.py de votre projet, il faut spécifier au moins un dossier. Il est d'usage de faire un dossier templates au sein de votre projet, et de spécifier ce dernier.

Dans ce dossier nous allons créer un fichier nommé base.html, celui ci contiendra le design html de notre charte graphique.

Autours des zones qui seront dynamiques, nous allons établir des blocks. Ces blocks sont souvent les mêmes :

• la zone de css
• la zone de javascript
• la balise title
• la zone de contenu
• la navigation

Exemple

<title>Mon site {% block title%}{% endblock %}</title>

Ensuite nous allons créer dans le dossier templates/npublisher de notre application un fichier nommé aussi base.html ce fichier héritera de notre fichier base.html créer précédemment. Ensuite il pourra surcharger les blocks hérités de son parent.

{% extends "base.html" %}

{% block title %}NPublisher{% endblock %}

Désormais dans chacun des templates de notre application, nous hériterons de application/base.html qui nous fournira une structure de template déjà configurée. Par exemple dans entry_list.html :

{% extends "npublisher/base.html" %}

{% block title %}{{ block.super }} Entrées{% endblock %}

Il suffit après de définir la zone de contenu à afficher dans le block représentant le contenu dans le template principal.

Si une modification doit être apportée sur tout le module au niveau du design, il suffit juste de modifier le fichier base.html de l'application.

2.5.1   Remarque

Nous voyons que nous avons rajouté à la première ligne, l'attribut objects. Ce n'est pas obligatoire, mais il est nécessaire de l'utiliser pour assurer une compatibilité avec les autres modules.

Pourquoi le déclarer alors ?

Car dans le fonctionnement des models, la première classe héritée de models.Manager, va devenir le manager par défaut de notre models. C'est une feature à prendre en compte lors de la conception de manager.

3.1.1   Internationalisation du code

Internationnaliser son code est souvent la première étape lors de l'internationalisation de votre application.

Il vous suffit de marquer chaque chaine qui devra être traduite, lors de l'écriture de votre code. En fonction du contexte la méthode a employé peut varier. Dans les models nous utiliserons des traductions à la volée, alors que dans les vues, les traductions peuvent être faites au lancement du serveur.

Prenons un exemple d'un model avant internationalisation :

>>> class News(models.Model):
>>>   reference = models.CharField(max_length=30)
>>>   categories = models.ForeignKey(Category)

Et maintenant après internationalisation :

>>> from django.utils.translation import ugettext, ugettext_lazy as _
>>>
>>> class News(models.Model):
>>>   reference = models.CharField(_('reference'), max_length=30)
>>>   categories = models.ForeignKey(Category, verbose_name=_('categories'))
>>>
>>>   class Meta:
>>>     verbose_name = _('news')

Il est important de se dire, qu'à cette étape nous marquons juste les strings devant être traduites.

3.1.2   Internationalisation des templates

Internationaliser le code n'est souvent que la première étape, car vos templates devront être aussi internationalisées.

Pour cela, il va falloir charger la machine de traduction à l'intérieur des templates, et comme pour l'étape précèdente, marquer les strings qui seront traduites.

{% load i18n %}
<h1>{% trans "news" %}</h1>

<p>{% trans "reference" %} : {{ object.reference }}</p>

3.1.3   Internationalisation du contenu en base de données

Parfois, il arrive que le contenu de la base de données ait besoin d'être lui même internationalisé. Prenons par exemple le cas de catégories insérées en base de données. Les catégories elles aussi ont besoin d'être traduites, mais Django ne fournit pas en standard un moyen de modéliser ce besoin en base de données.

Mais la communauté veille, et plusieurs applications existent pour répondre à ce besoin. Par exemple Multilingual

3.1.4   Détection de la langue

Django est bien pensé, le système d'acquisition de la langue de l'utilisateur est plutôt efficace. Par défaut il va vérifier s'il existe une valeur en session définissant la langue de l'utilisateur, le cas échéant, il va vérifier la présence d'un cookie qui définit les préférences de langue de l'utilisateur.

Si ces étapes ne retournent rien, il va regarder s'il existe une traduction pour la valeur Accept-Language de votre navigateur.

Arrivé jusque là, si il n'y a toujours pas de traduction, Django va afficher la traduction définie par la valeur LANGUAGE_CODE de votre fichier settings.py.

Ce système permet de toujours trouver une traduction, laissant le choix aux préférences de l'utilisateur.

3.1.5   Sélection de la langue

Il est facile de proposer à l'utilisateur le choix de sa langue. Le tout se fait par un formulaire HTML, et l'association d'une url.

Pour l'url :

>>>  (r'^i18n/', include('django.conf.urls.i18n')),

Pour le formulaire voici le code HTML :

<form action="/i18n/setlang/" method="post">
  <input name="next" type="hidden" value="/next/page/" />

  <select name="language">
  {% for lang in LANGUAGES %}
    <option value="{{ la
        ng.0 }}">{{ lang.1 }}</option>
  {% endfor %}
  </select>
  <input type="submit" value="Change" />

</form>

L'appel de cette vue va créer un cookie spécifiant la préférence de l'utilisateur et le rediriger vers la vue précèdente si la valeur next n'est pas présente.

3.1.6   Rédaction des traductions

Désormais nous avons tout le système mis en place pour avoir un site internationnalisé, mais il manque le plus important, les traductions.

Pour cela, nous allons créer un dossier locale soit au niveau de notre projet, soit de notre application, en fonction du besoin.

$> mkdir locale

Ensuite nous allons exécuter une commande qui va collecter tous les élements à traduire pour en faire un fichier PO, qui est la norme pour tout ce qui touche a l'internationalisation.

$> django-admin makemessages -l fr

Cette commande va créer les répertoires et le fichier PO qui contiendra la traduction française de notre projet ou application.

Si nous allons dans le dossier locale/fr/LC_MESSAGES, là se trouve notre fichier de traduction.

Nous devons l'éditer pour fournir les traductions, un simple éditeur de texte, peut faire l'affaire. Mais je conseille par exemple GTranslator qui fournit une interface efficace pour rapidement construire son fichier de traduction.

Maintenant que nous avons notre fichier PO préparé, il va être nécessaire de le compiler pour pouvoir l'utiliser dans notre application.

$> django-admin compilemessages

Il est aussi envisageable de le faire à la main avec la commande :

$> msgfmt django.po -o django.mo

Désormais nous avons un site entièrement traduit.

3.2.1   Modélisation des formulaires

La première étape est de modéliser un formulaire de façon pythonique pour pouvoir ensuite s'en servir comme objet de manipulation. Créons un formulaire qui va servir d'enregistrement sur le site.

>>> from django import forms
>>>
>>> class RegisterForm(forms.Form):
>>>   login = forms.CharField(max_length=50)
>>>   password_1 = forms.CharField(max_length=50, widget=forms.PasswordInput)
>>>   password_2 = forms.CharField(max_length=50, widget=forms.PasswordInput)

Désormais nous pouvons utiliser ce formulaire dans nos vues.

3.2.2   Rendus HTML

Bien entendu nous pouvons utiliser notre classe de formulaire pour en générer le rendu HTML au sein de nos templates.

<form method="post" action=".">
  {{ form }}
  <input type="submit" value="Connection" />

</form>

Mais il est aussi possible d'écrire soit même son formulaire en HTML, pour pouvoir en modifier le rendu visuel. Libre à vous, mais il faudra penser à inclure les cas où certains champs seront erronés.

3.2.3   Validation et contrôle

Nous avons donc un rendu de notre formulaire, mais il n'y a aucun contrôle effectué sur le contenu du formulaire. Il serait sain d'établir des contrôles tels que le login soit disponible et non enregistré, et que les 2 mots de passe, soient identiques.

Pour cela rien de plus simple, il suffit juste d'écrire certaines méthodes dans notre classe de formulaire.

>>> class RegisterForm(forms.Form):

>>>   ...
>>>   def clean_login(self):
>>>     try:
>>>       #mon code de test
>>>       pass
>>>     except:
>>>       forms.ValidationError(_("Your login is already in use !))
>>>     return self.cleaned_data['login']

>>>
>>>   def clean(self):
>>>     if self.cleaned_data.get('password_1') != self.cleaned_data.get('password_2'):
>>>       raise forms.ValidationError(_("Your passwords didn't match !"))
>>>     return self.cleaned_data

Lors de la validation du formulaire, Django va effectuer une vérification préliminaire sur les types de champs utilisés, puis si on écrit une méthode clean_FIELD, la méthode sera appliquée sur le champ pour faire un contrôle.

Si tout se déroule bien la méthode clean est appelée, et effectue une validation sur tous les champs.

Comme nous le voyons, la structure des formulaires est assez souple pour permettre beaucoup de personnalisation.

3.2.4   Vue associée

La dernière étape consiste à écrire une vue qui pourra traiter le formulaire. Plusieurs méthodes sont envisageables, mais il y a la bonne méthode et la mauvaise. Voici un exemple de bonne méthode :

>>> def subscribe(request):
>>>   if request.POST:
>>>     form = RegisterForm(request.POST, label_suffix=' :')
>>>     if form.is_valid():

>>>       form.save()
>>>       return HttpResponseRedirect('/roadshow/thankyou/')
>>>   else:
>>>     form = RegisterForm(label_suffix=' :')
>>>   return render_to_response('subscribe.html', {'form': form})

La bonne méthode comporte les point suivants :

• Vérifier que le contenu fournis est bien en POST
• Créer et utiliser la méthode save au sein des formulaires, par convention.
• Toujours rediriger avec une page une fois les données traitées pour éviter les doubles injections et autres problèmes de sécurité.

3.3.1   Fichiers statiques

Il reste cependant une chose à régler, comment servir les fichiers statiques de votre projet. Django peut très bien faire cela, mais une fois de plus, cette solution n'est ni adaptée ni optimisée, car Django sert à exécuter du code python et non à servir des fichiers.

Donc pour régler ce problème nous allons modifier la configuration Apache pour que ce soit Apache qui serve les fichiers statiques. Dans la section VirtualHost de votre configuration, il suffit de rajouter ceci pour chaque répertoire à servir.

Alias /css /repertoire/de/fichiers/static/css
<Location "/css">
   SetHandler None

</Location>

Le tour est joué.

4.1.1   docstring

Les docstrings en Python sont entourées de triple quote, ce qui permet un formatage libre au niveau des retours à la ligne et des doubles ou simple quotes.

Tout ce qui se trouve entre les triples quotes fait parti de la docstring de la fonction, qui décrit ce que fait la fonction. Une docstring, si elle existe, doit être la première chose déclarée dans une fonction (la première chose après les deux points). Techniquement parlant, vous n'êtes pas obligés de donner une docstring à votre fonction, mais vous devriez toujours le faire.

Beaucoup d'IDE Python utilisent les docstrings pour fournir une documentation contextuelle, ainsi lorsque vous tapez le nom d'une fonction, sa docstring apparaît dans une bulle d'aide. Cela peut être incroyablement utile, mais cette utilité est liée à la qualité de votre docstring.

Un exemple :

>>> def mafonction(a, b):
>>>   """Docstring de mafonction
>>>   Cette fonction ne fait rien"""
>>>   pass

4.1.2   Module doc

Django intègre dans sa version 1.0 un module lié au module d'administration permettant une review des models, des tags, des vues et des filtres. Ce module s'appelle django.contrib.admindocs, il est nécessaire de le rajouter dans la section INSTALLED_APPS, et de lui lier une url.

>>> (r'^admin/doc/', include('django.contrib.admindocs.urls')),

Ce module va se servir des docstring rédigées au sein de votre application pour générer une documentation globale de votre projet.

Il existe aussi d'autres modules indépendant de Django se basant sur la technique des docstring pour établir une documentation. Par exemple doctutils.

4.1.3   Conclusion

Documenter son application, c'est l'ouvrir aux autres. Il sera plus facile d'acquérir d'autres contributeurs si votre application est bien documentée.

Bien entendu les docstrings ne font pas tout, rien ne vous empêche par exemple de rédiger un fichier texte décrivant comment installer votre application, comment l'utiliser, ce qu'il reste à faire, ou à debugger. Libre à vous.

4.2.1   Tests unitaires

Les tests unitaires, permettent de tester une ou plusieurs parties de l'application, ils assurent la cohérence de chaque fonction ou méthode écrite dans l'application.

Prenons un exemple simple : si je code une fonction effectuant une addition, il est utile d'écrire un test, vérifiant que la fonction retourne le bon résulat.

>>> def add(a, b):
>>>   return a + b
>>> add(1, 41)
42

Bien évidemment rédiger tous ces tests de manière cohérente, est très long, heureusement, il existe des frameworks pour nous simplifier la tâche. Le plus populaire pour les tests unitaires en python est unittest, il est dérivé du framework JUnit écrit en Java.

4.2.2   Doc tests

Les doctests sont une variante de l'écriture des tests, elles combinent les avantages de la documentation et des tests. Rien de mieux que d'avoir sa documentation contenant des tests.

La rédaction de ces tests se fait à l'intérieur des docstrings.

>>> def add(a, b):
>>>   """Make an addition
>>>   >>> add(1, 41)
>>>   42
>>>   """

Cette technique permet d'avoir une cohérence entre la documentation et les tests qui illustrent la documentation.

4.2.3   Debugger avec les tests

Les tests unitaires permettent de debugger une application, prenons un cas simple : celui d'une fonction effectuant une division :

>>> def div(a, b)
>>>   return a / b

Cette fonction peut très bien marcher dans 99% des cas, mais il existe un cas où cela ne marche pas : la division par 0.

Donc il est nécessaire d'écrire un test, reproduisant le bug, et de corriger le code jusqu'à ce que l'ensemble des tests passent sans erreur.

>>> def div(a, b):
>>>   if b == 0:
>>>     raise "Can't divise by 0"
>>>   return a / b

4.3.1   Commandes principales

svn checkout

Permet de rapatrier le code source d'un projet.

svn commit

Publie les fichiers modifiés

svn diff

Permet de voir les modifications entre la copie locale et la copie distante.

svn status

Permet de voir le statut de chaque fichier provenant du SVN

svn revert

Permet de réinitialiser la copie locale par rapport à la copie distante