Le site d'administration de Django est génial – complet, facile à utiliser, sécurisé de par sa conception, solide comme le roc… et quelque peu laid, ce qui peut être quelque chose d'un inconvénient lorsque vous souhaitez l'intégrer avec le apparence et convivialité du reste de votre site Web.

Si ce n'est pas cassé…

Imaginons que vous venez de prototyper une application web avec Django et Vue.js . Pour un large éventail de cas, utiliser l'administrateur de Django à des fins de back-office tel quel, et même le gérer sur votre client après définir correctement les autorisations est très bien. Après tout, cela fonctionne parfaitement bien et il peut être fortement personnalisé avec les outils intégrés pour couvrir de nombreuses situations.

Encore une fois, pourquoi s'embêter?

Raisons de pirater l'apparence de l'administrateur

Cependant, il existe un certain nombre de raisons valables pour aller plus loin dans l'intégration:

• Branding : il n'y a rien de mal à vouloir le nom et les couleurs de votre entreprise au lieu de «Django administration» (et pour Pour mémoire, ceci est conforme à la licence BSD de Django ).
• Intégration transparente entre le site principal et l'administrateur : vous souhaiterez peut-être être en mesure de faire la transition entre les fonctionnalités de back-office lors de la navigation sur le site, et vice versa, en ayant une barre de navigation commune .
• Prettifying : alors que l'administrateur semble correct, et qu'il a même mis en œuvre des principes de conception de sites Web réactifs depuis la v2 ( ça marche bien sur mobile et sur ordinateur), il y a [1 9459026] beaucoup qu'une feuille de style bien conçue peut faire pour la rendre plus belle.
• Fonctionnalité de contournement : vous pouvez aussi simplement créer des menus déroulants personnalisés pour l'administrateur, affichant les options que vous avez réellement utiliser et masquer de l'interface utilisateur ce dont vous n'avez pas vraiment besoin, ce qui pourrait améliorer la expérience utilisateur .

Un exemple pratique

Pour cet exemple, et pour ne pas nous répéter, nous reprendrons la simple application de publication Web que nous avons lancée pour l'article Prototypage d'une application Web avec Django et Vue.js .

En résumé:

• une application Django avec deux modèles :
• Article avec champs nom auteur (lié), contenu et limace ]
• Auteur : avec champs nom et limace
• Une seule vue ca lled frontend qui interroge tous les registres dans les deux modèles.
• Un modèle unique appelé modèle .
• Implémentation de Vue.js avec Vue Routeur et Vuex pour une interface évolutive réactive.

Nous ne nous soucierons pas particulièrement de l'intégration de Vue.js dans cet épisode, et nous ne la modifierons pas ici.

Le Modèle de base

Les modèles Django sont très polyvalents et puissants et peuvent être créés au niveau de l'application (un composant du site Django) ou au niveau du site, et peut même remplacer les modèles fournis avec Django (ce que nous ferons ici).

Nous avons créé un modèle de base qui des liens vers le code JavaScript et la feuille de style de Bootstrap ainsi que ses outils associés, jQuery et Popper .

Voici le modèle de base que nous utilisons pour le site principal, pas du tout différent de ce que nous utiliserions normalement pour tout autre site Django:

  
    
    
    

    
    

    
  
  
    

      
 Prototypage une application Web avec Django et Vue.js 

      
    

           

Ensuite, nous allons l'intégrer dans l'administrateur et ajouter une barre de navigation partagée aux deux extrémités – le site principal et le back-office!

Intégration du modèle d'interface utilisateur principal avec l'administrateur

Comme mentionné, nous pouvons remplacer les modèles y compris ceux de l'administrateur. Cependant, en raison de la conception de Django, et sans surprise, le site principal et le back-office sont deux systèmes différents, chacun avec ses propres modèles, feuilles de style et contrib packages . Ainsi, même s'ils seront presque identiques, nous devrons conserver deux modèles différents – un pour l'interface utilisateur principale et un pour l'administrateur.

Activation d'un répertoire pour les modèles en général

Tout d'abord, nous devons indiquer à Django où nous allons stocker le modèle d'administration piraté dans le répertoire de base.

Par conséquent, nous devrons modifier myproject / settings.py . tout d'abord, trouver la constante MODELES et cette clé DIRS :

 'DIRS': [],

Remplacez ce code par:

 'DIRS': [os.path.join(BASE_DIR, 'templates')],

Emballage du modèle d'administration ( admin / base Hack)

Si nous voulions simplement apporter des modifications esthétiques, comme passer une feuille de style personnalisée à l'administrateur ou supprimer / remplacer son en-tête, nous pourrions s'entendre en éditant simplement le modèle admin / base_site et en ignorant complètement cette étape actuelle. Cependant, si nous voulons aller jusqu'au bout et « envelopper » la section admin comme si elle était contenue dans notre site principal, avec la possibilité d'avoir un en-tête et un pied de page communs, alors continuez à lire. [19659006] Nous devons copier admin / base.html de Django dans notre répertoire de modèles dans templates / admin / base.html afin de pouvoir placer nos wrappers.

Nous 'éditerai le code autour de la section container pour qu'il passe de ceci:

 (...)

à ceci:

 {% block bodyheader%} {% endblock%}



 (...)



 {% block bodyfooter%} {% endblock%}

Et c'est tout! Nous avons simplement créé les balises de bloc bodyheader et bodyfooter afin que nous puissions injecter le code qui encapsulera l'administrateur à l'étape suivante.

Codage d'un modèle d'administration personnalisé ( admin / base_site Hack)

Ensuite, nous coderons le modèle réel dans templates / admin / base_site.html (nous devrons créer les répertoires à la racine de notre projet) :

 {% étend "admin / base_site.html"%}

{% block title%} Django avec Bootstrap | Site d'administration {% endblock%}

{% block branding%} {% endblock%}
{% block breadcrumbs%} {% endblock%}

{% block bodyclass%} bg-light {% endblock%}

{% block extrastyle%}
    {% endblock%}

{% block bodyheader%}
    


      

        
 Piratage de l'administrateur Django avec Bootstrap 
        

           Le  site d'administration Django  est génial: complet, facile à utiliser, sécurisé par conception, solide comme le roc… et quelque peu laid, ce qui peut être une sorte de inconvénient lorsque vous souhaitez l'intégrer à l'apparence du reste du site Web. Voyons ça.
        
      
 {% endblock%}

{% block bodyfooter%}
    

        {% endblock%}

Répartition

Essayons d'expliquer ce que nous faisons ici:

1. Nous indiquons au moteur de modèle que nous «étendons» le modèle admin / base_site.html pour remplacer efficacement certains
2. Nous utilisons le bloc title pour personnaliser le titre de la page d'administration parcourue.
3. Nous vidons le contenu de la marque branding et
4. Nous utilisons le bloc bodyclass pour régler le bg-light de Bootstrap comme nous l'avons fait dans le modèle de frontend .
5. Nous utilisons le bloc extrastyle pour incorporer Bootstrap, et du code CSS.
a. D'accord, #header, .breadcrumbs {display: none; } est une sorte de retraitement du numéro 3; mais il est utile de savoir que vous pouvez désactiver les sections d'image de marque et de fil d'Ariane dans les deux sens.
b. Il peut y avoir des problèmes lors du chevauchement de Bootstrap avec le CSS de Django dans l'administrateur, donc ce sont des correctifs.
6. Utilisez les blocs bodyheader et bodyfooter pour encapsuler le contenu administrateur. [19659073] Maintenant que nous avons accès au modèle d'administration, nous pouvons approfondir sa feuille de style, ou tout simplement le laisser avec un style partagé avec l'interface utilisateur principale.

   Mises en garde

   Nous conservons deux modèles différents (interface utilisateur principale) et admin) pour faire essentiellement la même présentation. Certes, ce n'est pas idéal, car nous brisons explicitement l'une des maximes du développement logiciel: ne vous répétez pas (SEC).

   Comme nous l'avons commenté, c'est parce que l'administrateur Django a été conçu pour être détaché de l'interface utilisateur principale. Et il n'y a rien de mal à cela, tout comme il n'y a rien de mal à sortir des sentiers battus. Mais oui, cela nous oblige à utiliser deux modèles avec presque le même contenu.

   En fait en principe, nous pourrions concevoir un modèle de modèle qui inclurait cette barre de navigation et d'autres éléments communs de l'interface utilisateur principale et de l'administrateur et réutilisez-les à partir de cette source unique; mais à ce stade, et aux fins de cet article, cette approche serait un peu exagérée. Quoi qu'il en soit, je vais laisser l'idée plantée pour vous. 1965

   Création d'une barre de navigation partagée

   Maintenant que l'interface utilisateur principale et le site d'administration se ressemblent, nous pouvons aller plus loin dans notre intégration et faire une expérience de navigation commune… et même plus loin, présenter quelques options d'administration directement sur le menu principal!

   Voici l'extrait de la barre de navigation:

   Remarquez la section du menu déroulant qui se chargera de présenter un menu d'administration (voir le composant Bootstrap Navbar pour plus d'informations).

   Nous faisons également un vérification conditionnelle avec {% if user.is_authenticated%} / {% endif%} pour décider d'afficher ou non le menu d'administration.

   Enfin, rappelez-vous que, puisque nous maintenons maintenant deux modèles principaux différents, nous devons ajouter le code HTML de la barre de navigation aux deux, myapp / templates / myapp / tempalte.html et templates / admin / base_site.html .

   Le site d'administration a été pris en charge, mais il y a encore une extrémité libre: l'écran de connexion.

   Maintenant, nous pouvons tourner quelque chose comme ceci:

   

   … en quelque chose comme ceci:

   

   Nous pouvons accomplir quelque chose de plus proche de cela en créant le modèle suivant dans templtes / admin / login.html :

    {% extend "admin / login.html"%}
   
   {% load i18n static%}
   
   {% block extrastyle%}
   {{block.super}}{% endblock%}
   
   {% bloquer l'image de marque%}
   
      ActionPlanNow.com 
     
   
      {% block head_title%} {% endblock%} 
   
    {% endblock%}
   
   {% block content_title%}
   
   Un outil simple pour les dirigeants, les entraîneurs et les conseillers.
   
   {% endblock%}
   

   Répartition

   Ce que nous faisons ici:

   1. La ​​balise {{block.super}} est là pour indiquer au moteur de modèle que nous ne remplaçons pas le contenu de extrastyle (que nous avons défini dans le modèle templates / admin / base_site.html ) mais que nous y ajoutons simplement du contenu (voir héritage du modèle pour plus d'informations) .
   2. Le bloc de marque nous permet de changer l'en-tête "Administration Django" en quelque chose de plus intéressant.
   3. Nous nous débarrassons du bloc head_title en définissant une définition vide.
   4. Nous utilisons le bloc content_title pour ajouter des informations supplémentaires.

   Quelques considérations

   

   Tout comme Bootstrap, l'administrateur Django le site expédie également son propre paquet de jQuery mais heureusement, les développeurs de Django ont réfléchi et évité en conflit avec les scripts et les bibliothèques fournis par l'utilisateur, jQuery de Django est doté d'un espace de nom django.jQuery . Nous pouvons donc inclure votre propre copie (comme nous l'avons fait) en toute sécurité.

   Soyez prudent lorsque vous devenez fou avec les définitions de classe dans votre feuille de style principale, car cela affectera également le site d'administration, affectant sa fonctionnalité de manière inattendue. Dans ce cas, vous pouvez toujours voir ce qui se passe avec les outils de débogage de votre navigateur, tels que Chrome DevTools Firefox Developer Tools (en particulier Page Inspector ), ou Safari Developer Tools .

   Démo et code complet

   Cette implémentation dont nous avons discuté ici ressemblera à ceci:

   Vous pouvez parcourir tout le code du projet dans mon référentiel GitHub, luzdealba / djangovuejs .

   Wrap Up

   Alors que certains pourraient prétendre - assez raisonnablement - qu'il n'y a pas grand-chose à faire modifier l'apparence d'administration de Django, il est également vrai que intégrer en douceur les différents points de terminaison d'un site est un bon hack pour une meilleure UX car il peut fournir une transition transparente entre les deux, et même une navigation plus contrôlée de l'administrateur

   Et ce n'est pas si difficile. Ce que vous devez faire attention, c'est comment vous envelopper l'administrateur, et aussi comment vous mélangez les bibliothèques tierces avec votre propre code JavaScript et vos propres feuilles de style. Heureusement, vous pouvez très facilement en intégrer certains dans l'administrateur, d'autres dans le reste du site principal et d'autres dans les deux.

   J'espère que vous avez des idées sur la façon de personnaliser Django de manière différente.

   Si vous avez besoin d'une excuse pour créer une application Web afin de pouvoir jouer avec l'administrateur Django, consultez le didacticiel de la semaine dernière sur le prototypage d'une application Web avec Django et Vue.js - c'est un tonne de plaisir. Et si vous voulez approfondir vos compétences Django, la bibliothèque SitePoint Premium a des tas de ressources pour vous.