L’admin generator de Django vu par un développeur symfony

Quoi de plus fastidieux que de réimplémenter encore et encore un CRUD (Create, Retrieve, Update, Delete) ?
Ces opérations élémentaires sont cependant les plus courantes en traitement des données.
Heureusement, de plus en plus de frameworks web offrent la possibilité de les générer à partir du modèle de données : de la requête Sql au Html.
Voyons comment se débrouille Django sur ce terrain !

Introduction

J’ai testé récemment l’admin generator (AG) de Django. C’est un composant important qui fait gagner beaucoup de temps et utilise presque tout le reste du framework.

Nous verrons dans ce billet ce qui le différencie de l’AG symfony d’un point de vue fonctionnel.

Note : dans les exemples je parlerai d’articles, de commentaires et de tags. Ce sont les entités que j’ai choisies pour mes tests. On a une relation 1,n entre article et commentaire et une relation n,n entre article et tag.

Version de Django testée : 1.1

Génération d’une « vraie » application

Alors que symfony génère de manière isolée des CRUD, Django offre une application avec authentification, dashboard avec menus et historique des actions, gestion des utilisateurs/groupes/permissions et fil d’ariane. Le tout dans un design épuré très agréable.

Ajout d’entités liées

Exemple : lorsque l’on crée un article on n’a pas forcément pensé à créer ses tags auparavant. Or c’est à la création/modification de l’article que je veux les lier. Pour éviter des aller-retour, Django ajoute un bouton + permettant d’ajouter des tags sans quitter le formulaire d’article :

Même chose pour les commentaires (relation 1,n) :

Autre solution possible, l’ajout par lot (cette fois avec des sondages et des choix) :

Alternative aux grandes listes déroulantes

En cas de grosse volumétrie, il n’est parfois pas possible de proposer une liste déroulante pour des raisons de performances et d’ergonomie. Django propose un système de sélection reprenant la vue « liste » :

Dans cet exemple il suffit de cliquer sur le titre d’un article pour le sélectionner. Le champ de saisie affichant 1 correspond à l’id de l’article sélectionné : je ne pense pas que ça soit une très bonne idée de l’afficher par défaut.

« Enregistrer sous »

C’est une fonctionnalité simple mais pratique. Prenons un exemple avec des devis : je souhaite créer un devis sans partir de zéro. Il existe en base un devis similaire à celui que je veux établir. Je clique sur ce dernier, puis sur « Enregistrer sous » : le système duplique le devis. C’est une sorte de copier-coller.

Afficher les boutons d’action en haut et en bas

Petit détail, mais une option permet d’accéder aux actions en haut du formulaire. On n’a pas besoin de surchager de template et c’est pratique pour les grands formulaires ou les grandes listes.

Sélecteur de date

Modification dans la liste

Pour certaines entités avec peu d’attributs, ce mode d’édition est apprécié.

Historique des actions

Pour chaque entité, Django enregistre les actions effectuées :

Champ de recherche unique et filtres

La recherche se fait à partir d’un simple champ texte.
Cependant, même si on peut spécifier les attributs dans lesquels chercher, il serait bon d’avoir la possibilité d’effectuer une recherche avancée (qui ressemblerait à la recherche symfony par exemple).

Les filtres sont assez limités et ne semblent utiles que pour les attributs booléens et temporels :

Suppression

Lorsque l’on supprime un objet lié à d’autres objets, on obtient le message suivant :

(il ne manque plus que la traduction de la première phrase…)

Un peu de technique

Côté développement, les moyens de personnalisation ressemblent beaucoup à ceux de symfony.

Les options de génération sont initialisées dans des classes qui correspondent aux generator.yml de symfony. Leur écriture n’est pas beaucoup plus verbeuse grâce à la syntaxe concise de Python (qui ressemble d’ailleurs au Yaml pour les dictionnaires et les tableaux).

Ensuite, pour une personnalisation complète, on retrouve les classes de formulaire (widgets, validation) et la surcharge des actions et des templates.

Conclusion

L’AG (Admin Generator) de Django est de très bonne qualité et j’avoue le préférer à celui de symfony. Avant de rédiger ce billet j’ai comparé point à point leurs fonctionnalités et je me suis vite rendu compte que Django offrait plus de fonctionnalités avec une meilleure ergonomie « out of the box ». La documentation est également très réussie.

Django influencera-t-il symfony sur ce composant qui fait souvent office de démonstration du framework ?