3. Topics¶
3.1. Admin¶
La configuration d’urls livré par défaut monte l’admin Wagtail sur /admin et conserve l’admin Django sur /django-admin.
La “fabrication” de l’admin Wagtail repose sur une définition de panels (reliant un widget à chaque field) à l’intérieur même de chaque modèle.
3.2. Arborescence¶
Contrairement à DjangoCMS qui est fait pour ne gérer qu’une arborescence unique, Wagtail introduit la notion de “racine” qui définit le point d’entrée pour chaque Site configuré et sa propre arborescence. On peut évidemment ensuite avoir plusieurs racines.
Outre le fait que l’on puisse servir plusieurs sites différents (chacun avec leur propre racine) depuis une instance unique de Wagtail, ce système multi-sites est aussi un moyen simple (mais très rudimentaire) d’implémenter la traduction de site, chaque langue ou pays ayant alors sa propre arborescence (partant de sa propre racine).
À noter que contrairement à DjangoCMS, l’arborescence complètement développée n’est pas visible et l’on accède aux sous-pages en traversant leur chemin parent par parent.
3.3. Assets¶
Bien qu’il ne soit pas une dépendance direct de Wagtail, la norme semble être d’utiliser django-compressor, on le retrouve notamment dans la démo officielle et dans Puput.
3.4. Formulaires¶
Un générateur de formulaire est disponible depuis l’administration, il permet de créer un formulaire qui deviendra une page à part entière. On définit les champs, leur type, valeurs par défaut, etc.. de chaque formulaire, ainsi que d’autres options supplémentaires que l’on peut définir dans le modèle de formulaire (à la façon d’un modèle de page).
Il est cependant explicitement avertit que son usage est limité. Ce ne sont que des formulaires de collecte de données, sans autres possiblités de traitement de celle ci. De plus la mise en forme est automatique et donc basique, il n’est pas possible de contrôler la disposition des champs (tel que deux champs sur une même ligne), des class CSS ou attributs HTML spécifiques.
Il semble peu probable d’y adjoindre quelque chose comme crispy-form pour améliorer la mise en forme de ces formulaires.
3.5. Modèles¶
Les modèles de pages sont à cheval entre les modèles de données, le modèle d’admin et les vues.
Un modèle de page hérite toujours du modèle wagtail.wagtailcore.models.Page et définit les champs de contenu, les widgets admin de ces champs et peut intervenir sur la vue de ce modèle (contexte dans le template, comment est servi la page, etc..).
Sur des modèles élaborés celà amène rapidement à contrevenir au principe MVC, une application tente de corriger cette situation.
3.6. Settings¶
Depuis la dernière version de Wagtail, les projets créé via son outil CLI adoptent la nouvelle organisation des settings de Django.
À ne pas confondre avec la partie Settings dans l’admin qui héberge les composants qui ne fournissent pas de contenus (Utilisateurs, groupes, redirections, etc..).
3.7. Site¶
django.contrib.sites est désactivé dans la conf par défaut d’un projet Wagtail car il utilise à la place wagtail.wagtailsites qui est une extension du Site framework de Django. Cette extension dissocie le hostname et le port utilisé et inclus la notion de racine lié à l’arborescence multi-sites de Wagtail.
3.8. Snippet¶
Tout comme les Snippets de DjangoCMS ce sont des fragments de contenus indépendant des pages. Cependant dans Wagtail tout comme avec une page, on y séléctionne un type de contenu modélisé sans accéder à son HTML. Il n’y a pas non plus de template tag commun pour accéder à un snippet, chaque type de snippet doit implémenter son propre template tag si nécessaire.
3.9. Templates¶
Les templates de chaque modèles sont recherchés avec le même concept que les vues génériques Django le font.
Contrairement à DjangoCMS, l’on accède plus naturellement aux contenus d’une page Wagtail comme on le fait avec des applications basiques Django.
3.10. Utilisateurs¶
L’admin Wagtail pour la gestion des utilisateurs change quelque peu, principalement à un niveau cosmétique mais aussi du fait que l’on y gère plus directement les permissions, seulement l’appartenance à des groupes ou non.
La définition de ces groupes se faisant depuis la partie Settings de l’admin Wagtail.