Approfondissements

Générer d’autres formats que du HTML

Personnaliser le modèle « USER MODEL » de Django

Le modèle de gestion des utilisateurs utilisé par Django et que l’on trouve dans django.contrib.auth est très pratique puisque l’on peut immédiatement construire un site gérant tous les aspects de base de l’enregistrement et du contrôle des utilisateurs, login, sessions, droits d’accès, etc. Seulement il va arriver un moment où l’on souhaite pouvoir personnaliser ce modèle pour lui ajouter de nouveaux comportements, de nouveaux champs ou même une logique particulière. C’est bien sûr faisable et peut être réalisé de plusieurs façons en fonction du but recherché.

Si l’on souhaite simplement enrichir le modèle User existant, car on en est globalement satisfait et que l’on n’a pas besoin de rajouter des champs, il suffit d’utiliser un modèle proxy, pour cela reportez-vous au chapitre L’ORM et les modèles Django à la section concernant l’héritage, il n’y a aucune difficulté à réaliser cela.

Si l’on souhaite simplement ajouter des champs mais sans créer son propre modèle de gestion des utilisateurs, le plus simple est de relier une « extension », qui est un modèle Django contenant les champs et le comportement spécifiques au modèle User existant par une relation un vers un.

Enfin, si on souhaite aller plus loin dans la modification du modèle de gestion des utilisateurs, il faudra créer un modèle spécifique respectant certaines règles et contraintes et l’installer dans Django.

Une réelle difficulté pour personnaliser le modèle User va apparaitre dès que l’on va vouloir étendre le modèle User de Django et, en même temps, utiliser une ou plusieurs applications tierces ; applications qui ont elles-mêmes personnalisé le modèle User. Vous risquez de devoir soit renoncer à utiliser une application, soit accepter d’avoir des champs en doublon, soit réécrire entièrement un modèle réalisant la synthèse entre les différents modèles User. Bref, cela peut s’avérer assez problématique. Cela...

Les signaux

Django propose un mécanisme très utile qui est un gestionnaire de signaux. Les signaux sont émis par un émetteur à destination de récepteurs qui se sont enregistrés sur le signal. Le récepteur est une fonction Python. Cela permet d’être informé lorsque certaines opérations sont réalisées quelque part dans le framework.

Vous pouvez créer vos propres signaux pour votre application et Django contient un ensemble de signaux pour les actions courantes du framework. En voici les principaux :

Les signaux relatifs aux modifications des instances de modèles :

django.db.models.signals.pre_save et django.db.models.signals.post_save

Qui sont des signaux respectivement activés avant et après l’appel à la méthode save().

django.db.models.signals.pre_delete et django.db.models.signals.post_delete

Qui sont des signaux respectivement activés avant et après l’appel à la méthode delete() d’une instance ou d’un QuerySet.

django.db.models.signals.pre_init et django.db.models.signals.post_init

Qui sont des signaux respectivement activés avant et après la création d’une instance.

django.db.models.signals.m2m_changed

Qui est activé lorsqu’un champ ManyToManyField est modifié.

Les signaux relatifs aux requêtes :

django.core.signals.request_started et django.core.signals.request_finished

Qui sont activés avant que Django débute ou termine une requête HTTP.

django.core.signals.got_request_exception

Qui est activé par une exception...

La sécurité

La création de commandes en mode console

manage.py permet d’exécuter un certain nombre de commandes, runserver, shell, syncdb, migrate, etc. Les développeurs Django ont la possibilité d’enrichir la liste des commandes disponibles en ajoutant les commandes de leur application.

À quoi cela sert-il ? Un site peut avoir à exécuter périodiquement certaines opérations de vérification ou de nettoyage, pouvoir les lancer sous la forme d’une commande (d’un script) ou pouvoir les automatiser en les installant dans la crontab d’UNIX ou son équivalent Windows (tâches programmées).

Pour cela il faut créer un répertoire management/commands à votre application. Django enregistrera automatiquement les commandes définies, c’est-à-dire les modules de ce répertoire qui ne commencent pas par le caractère « _ » (underscore). Vous devez donc respecter la structure suivante de fichiers pour votre projet :

mon_application/  
    __init__.py  
    admin.py  
    models.py  
    management/  
        __init__.py  
        commands/  
            __init__.py  
            _ne_pas_charger.py 
            archiver.py  
   views.py 
 

Dans cet exemple, la commande « archiver »...

Les exceptions

En plus des exceptions Python traditionnelles, Django possède ses propres exceptions réparties en quatre catégories : celles du noyau Django (core), celles relatives aux URL, celles relatives aux bases de données et celles relatives à HTTP.

DoesNotExist 
 

ObjectDoesNotExist
 

MultipleObjectsReturned
 

SuspiciousOperation
 

PermissionDenied
 

ViewDoesNotExist
 

MiddlewareNotUsed