Templating sauve des lignes (partie 2)

Certaines approches simples pour créer des sites Web nécessitent qu'un développeur écrive chaque ligne de HTML à la main. À l'autre extrême, les constructeurs de sites commerciaux sans code créent automatiquement tout le code HTML pour l'utilisateur, souvent au détriment de la lisibilité dans le code résultant. Les modèles se situent au milieu de ce spectre, mais plus proches du HTML manuscrit que, par exemple, la génération d'une structure de page dans une application d'une seule page à l'aide de React ou d'une bibliothèque similaire. Ce point idéal sur le continuum offre de nombreux avantages du HTML manuel à partir de zéro (code sémantique / lisible, contrôle total de la structure de la page, chargement rapide des pages) et ajoute une séparation des préoccupations et de la concision, le tout au détriment du temps passé à écrire HTML modifié à la main. Cet article montre comment utiliser Django pour créer des modèles de pages complexes.

Le sujet d'aujourd'hui s'applique au-delà du cadre Django. Flask (un autre framework web) et Pelican (un générateur de site statique) ne sont que deux des nombreux autres projets Python qui utilisent la même approche de création de modèles. Jinja2 est le moteur de modèles que les trois cadres utilisent, bien que vous puissiez en utiliser un autre en modifiant les paramètres du projet (à proprement parler, Jinja2 est un sur-ensemble de modèles Django). Il s'agit d'une bibliothèque autonome que vous pouvez incorporer dans vos propres projets même sans framework, donc les techniques de cet article sont largement utiles.

Rendu côté serveur

Un modèle n'est qu'un HTML fichier dans lequel le code HTML a été étendu avec des symboles supplémentaires. Rappelez-vous ce que signifie HTML: H yper T ext M arkup L anguage. Jinja2, notre langage de création de modèles, ajoute simplement au langage avec des symboles de balisage significatifs supplémentaires. Ces structures supplémentaires sont interprétées lorsque le serveur restitue le modèle pour servir une page HTML simple à l'utilisateur (c'est-à-dire que les symboles supplémentaires du langage de modèles ne parviennent pas dans la sortie finale).

Côté serveur Le rendu est le processus de construction d'une page Web en réponse à une demande. Django utilise le rendu côté serveur pour servir des pages HTML au client. À la fin de son exécution, une fonction de vue combine la demande HTTP, un ou plusieurs modèles et éventuellement des données accessibles pendant l’exécution de la fonction pour construire une seule page HTML qu’elle envoie en réponse au client. Les données vont de la base de données, à travers la vue, et dans le modèle pour se rendre à l'utilisateur. Ne vous inquiétez pas si cette explication abstraite n'a pas de sens, nous allons nous tourner vers un exemple concret pour le reste de cet article.

Configuration

Pour notre exemple, nous prendrons une page Web assez complexe , Démarrez le modèle d'administration de Bootstrap et réécrivez le code HTML en tant que modèle Jinja2. Notez que la bibliothèque sous licence MIT utilise un système de modèles différent (basé sur JavaScript et Pug) pour générer la page que vous voyez, mais leur approche diffère considérablement des modèles de style Jinja2, donc cet exemple est plus une rétro-ingénierie qu'une traduction de leur excellent projet open-source. Pour voir la page Web que nous allons créer, vous pouvez consulter Démarrer l'aperçu en direct de Bootstrap .

J'ai préparé un exemple d'application pour cet article. Pour exécuter le projet Django sur votre propre ordinateur, démarrez votre environnement virtuel Python 3 puis exécutez les commandes suivantes:

 pip install django
git clone https://github.com/philipkiely/sm_dh_2_dashboard.git
cd sm_dh_2_dashboard
migration de python manage.py
python manage.py crée un superutilisateur
python manage.py loaddata employee_fixture.json
python manage.py runserver

Ensuite, ouvrez votre navigateur Web et accédez à http://127.0.0.1:8000 . Vous devriez voir la même page que l'aperçu, correspondant à l'image ci-dessous.

Comme ce didacticiel est axé sur l'interface, l'application Django sous-jacente est très simple. Cela peut sembler beaucoup de configuration pour présenter une seule page Web, et pour être juste, c'est. Cependant, cette configuration peut également prendre en charge une application beaucoup plus robuste.

Maintenant, nous sommes prêts à parcourir le processus de transformation de ce fichier HTML de 668 lignes en un site Django correctement architecturé.

Templating And Inheritance

La première étape de la refactorisation de centaines de lignes de code HTML en code propre consiste à diviser les éléments en leurs propres modèles, que Django composera en une seule page Web pendant l'étape de rendu.

Jetez un coup d'œil dans pages / modèles . Vous devriez voir cinq fichiers:

• base.html le modèle de base que chaque page Web étendra. Il contient le avec le titre, les importations CSS, etc.
• navbar.html le code HTML de la barre de navigation supérieure, un composant à inclure si nécessaire.
• footer.html , le code pour le pied de page, un autre composant à inclure si nécessaire.
• sidebar.html le HTMl pour la barre latérale, un troisième composant à inclure si nécessaire.
• index.html , le code unique de la page principale. Ce modèle étend le modèle de base et inclut les trois composants.

Django assemble ces cinq fichiers comme Voltron pour rendre la page d'index. Les mots clés qui le permettent sont {% block%} {% incluent%} et {% extend%} . Dans base.html :

 {% block content%}
{% endblock%} 

Ces deux lignes laissent de l'espace aux autres modèles qui étendent base.html pour insérer leur propre code HTML. Notez que le contenu est un nom de variable, vous pouvez avoir plusieurs blocs avec des noms différents dans un modèle, ce qui donne de la flexibilité aux modèles enfants. Nous voyons comment étendre cela dans index.html :

 {% étend "base.html"%}
{% block content%}

{% endblock%} 

L'utilisation du mot-clé étend avec le nom du modèle de base donne à la page d'index sa structure, nous évitant de copier dans l'en-tête (notez que le nom de fichier est un chemin relatif en double- entre guillemets). La page d'index comprend les trois composants communs à la plupart des pages du site. Nous apportons ces composants avec les balises comme ci-dessous:

 {% étend "base.html"%}
{% block content%}
{% incluent "navbar.html"%}
{% incluent "sidebar.html"%}

{% incluent "footer.html"%}

{% endblock%} 

Dans l'ensemble, cette structure offre trois avantages clés par rapport à l'écriture de pages individuellement:

• Code SEC (ne vous répétez pas)
  En intégrant le code commun dans des fichiers spécifiques, nous pouvons changer le code en un seul endroit et refléter ces changements sur toutes les pages.
• Meilleure lisibilité
  Plutôt que de faire défiler un fichier géant, vous pouvez isoler le composant spécifique qui vous intéresse.
• Séparation des préoccupations
  Le par exemple, la barre latérale maintenant doit être au même endroit, il ne peut pas y avoir de balises de script voyous flottant au bas du code ou tout autre mélange entre ce qui devrait être composants séparés. L'affacturage des pièces individuelles force cette bonne pratique de codage.

Bien que nous puissions économiser encore plus de lignes de code en plaçant les composants spécifiques dans le modèle base.html les garder séparés offre deux avantages. La première est que nous pouvons les intégrer exactement là où ils appartiennent dans un seul bloc (cela ne concerne que le footer.html qui va à l'intérieur du div principal du ] contenu bloc). L'autre avantage est que si nous devions créer une page, disons une page d'erreur 404, et que nous ne voulions pas la barre latérale ou le pied de page, nous pourrions les laisser de côté.

Ces capacités sont normales pour le cours de création de modèles. Maintenant, nous nous tournons vers des balises puissantes que nous pouvons utiliser dans notre index.html pour fournir des fonctionnalités dynamiques et enregistrer des centaines de lignes de code.

Deux balises fondamentales

Ceci est très loin d'être exhaustif liste des balises disponibles. La documentation de Django sur les modèles fournit une telle énumération. Pour l'instant, nous nous concentrons sur les cas d'utilisation de deux des éléments les plus courants du langage de création de modèles. Dans mon propre travail, j'utilise essentiellement les balises pour et if régulièrement, bien que la douzaine d'autres balises prévues aient leur propre cas d'utilisation, ce que je vous encourage à revoir dans la référence de modèle .

Avant de passer aux balises, je veux faire une note sur la syntaxe. La balise {% foo%} signifie que "foo" est une fonction ou une autre capacité du système de modélisation lui-même, tandis que la balise {{bar}} signifie que "bar" est

Pour les boucles

Dans le reste index.html la plus grande section de code de plusieurs centaines de lignes est le tableau. Au lieu de cette table codée en dur, nous pouvons générer la table dynamiquement à partir de la base de données. Rappelez python manage.py loaddata employee_fixture.json à partir de l'étape de configuration. Cette commande a utilisé un fichier JSON, appelé Django Fixture, pour charger les 57 enregistrements d'employés dans la base de données de l'application. Nous utilisons la vue dans views.py pour transmettre ces données au modèle:

 à partir de django.shortcuts import render
depuis .models import Employee

index de déf (demande):
    return render (request, "index.html", {"employees": Employee.objects.all ()}) 

Le troisième argument positionnel du render est un dictionnaire de données mis à la disposition de le gabarit. Nous utilisons ces données et la balise for pour construire la table. Même dans le modèle d'origine à partir duquel j'ai adapté cette page Web, le tableau des employés était codé en dur. Notre nouvelle approche coupe des centaines de lignes de lignes répétitives codées en dur. index.html contient désormais:

 {% pour employé en employés%}
  <trv
     {{employee.name}} 
     {{employee.position}} 
     {{employee.office}} 
     {{employee.age}} 
    vtd> {{employee.start_date}} 
     $ {{employee.salary}} 
  
 {% endfor%} 

Le plus grand avantage est que cela simplifie considérablement le processus de mise à jour de la table. Plutôt que de demander à un développeur de modifier manuellement le code HTML pour refléter une augmentation de salaire ou une nouvelle embauche, puis de pousser ce changement en production, tout administrateur peut utiliser le panneau d'administration pour effectuer des mises à jour en temps réel ( http://127.0.0.1/ admin utilisez les informations d'identification que vous avez créées avec python manage.py createuperuser pour y accéder). C'est un avantage d'utiliser Django avec ce moteur de rendu au lieu de l'utiliser seul dans un générateur de site statique ou une autre approche de création de modèles.

If Else

La balise if est une balise incroyablement puissante qui vous permet d'évaluer les expressions dans le modèle et d'ajuster le HTML en conséquence. Des lignes comme {% if 1 == 2%} sont parfaitement valides, quoique un peu inutiles, car elles évaluent le même résultat à chaque fois. Lorsque la balise if brille, c'est lors de l'interaction avec les données transmises au modèle par la vue. Prenons l'exemple suivant de sidebar.html :

 

  

    Connecté en tant que:
  
  {% if user.is_authenticated%}
    {{user.username}}
  {% autre %}
    Démarrer Bootstrap
  {% fin si %}
 

Notez que l'objet utilisateur entier est passé dans le modèle par défaut, sans que nous spécifions quoi que ce soit dans la vue pour que cela se produise. Cela nous permet d'accéder au statut d'authentification de l'utilisateur (ou à son absence), à ​​son nom d'utilisateur et à d'autres fonctionnalités, y compris les relations de clé étrangère suivantes pour accéder aux données stockées dans un profil utilisateur ou un autre modèle connecté, le tout à partir du fichier HTML.

Vous pourriez craindre que ce niveau d'accès ne pose des risques pour la sécurité. Cependant, n'oubliez pas que ces modèles sont destinés à une infrastructure de rendu côté serveur. Après avoir construit la page, les balises se sont consommées et sont remplacées par du HTML pur. Ainsi, si une instruction if introduit des données dans une page sous certaines conditions, mais que les données ne sont pas utilisées dans une instance donnée, alors ces données ne seront pas du tout envoyées au client, comme le L'instruction if est évaluée côté serveur. Cela signifie qu'un modèle correctement construit est une méthode très sécurisée pour ajouter des données sensibles aux pages sans que ces données quittent le serveur, sauf si cela est nécessaire. Cela dit, l'utilisation des modèles Django ne supprime pas la nécessité de communiquer des informations sensibles de manière sécurisée et cryptée, cela signifie simplement que des contrôles de sécurité comme user.is_authenticated peuvent se produire en toute sécurité dans le code HTML lors de leur traitement. côté serveur.

Cette fonctionnalité a un certain nombre d'autres cas d'utilisation. Par exemple, dans une page d'accueil de produit générale, vous souhaiterez peut-être masquer les boutons «S'inscrire» et «Se connecter» et les remplacer par un bouton «Se déconnecter» pour les utilisateurs connectés. Une autre utilisation courante consiste à afficher et masquer les messages de réussite ou d'erreur pour des opérations telles que la soumission de formulaires. Notez qu'en général, vous ne masqueriez pas la page entière si l'utilisateur n'est pas connecté. Une meilleure façon de modifier la page Web entière en fonction du statut d'authentification de l'utilisateur est de la gérer dans la fonction appropriée dans views.py

Filtrage

Une partie du travail de la vue consiste à formater les données de manière appropriée pour la page. Pour ce faire, nous avons une extension puissante pour les balises: les filtres. Il existe de nombreux filtres disponibles dans Django pour effectuer des actions telles que la justification du texte, la mise en forme des dates et l'ajout de nombres. Fondamentalement, vous pouvez considérer un filtre comme une fonction appliquée à la variable d'une balise. Par exemple, nous voulons que nos chiffres de salaire se lisent «1 200 000 $» au lieu de «1 200 000». Nous utiliserons un filtre pour effectuer le travail dans index.html :

  $ {{employee.salary | intcomma}} 

Le caractère pipe | est le filtre qui applique la commande intcomma à la variable employee.salary . Le caractère "$" ne vient pas du modèle, pour un élément comme celui qui apparaît à chaque fois, il est plus facile de le coller juste en dehors de la balise.

Notez que intcomma nous oblige à inclure {% load humanize%} en haut de notre index.html et 'django.contrib.humanize', dans notre INSTALLED_APPS dans settings.py . Ceci est fait pour vous dans l'exemple d'application fourni.

Conclusion

Le rendu côté serveur avec le moteur Jinja2 fournit des outils clés pour créer un code frontal propre, adaptable et réactif. La séparation des pages en fichiers permet des composants SECS avec une composition flexible. Les balises offrent des capacités fondamentales pour afficher les données transmises depuis la base de données par les fonctions d'affichage. Bien exécutée, cette approche peut augmenter la vitesse, les capacités de référencement, la sécurité et la convivialité du site, et est un aspect central de la programmation dans Django et les cadres similaires.

Si vous ne l'avez pas déjà fait, consultez le exemple d'application et essayez d'ajouter vos propres balises et filtres à l'aide de la liste complète .

Django Highlights est une série présentant des concepts importants de développement Web à Django. Chaque article est écrit comme un guide autonome sur une facette du développement de Django destiné à aider les développeurs et les concepteurs frontaux à approfondir leur compréhension de «l'autre moitié» de la base de code. Ces articles sont principalement conçus pour vous aider à mieux comprendre la théorie et les conventions, mais contiennent des exemples de code, qui sont écrits dans Django 3.0.

(dm, yk, il)