Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Creative Coding
Code

Améliorer votre flux de travail - Séparez votre marge bénéficiaire de votre logique!

by
Length:LongLanguages:

French (Français) translation by honeymmmm (you can also view the original English article)

Dans ce tutoriel, je vais vous expliquer une technique qui vous permet d'utiliser un fichier de modèle pour tous vos besoins en HTML! Vous n'aurez plus besoin de "faire écho" les chaînes depuis vos fonctions, ni de vous soucier de passer du PHP à la sortie pour sortir du balisage.

J'ai passé de nombreuses années à utiliser les frameworks MVC (tels que Zend et Laravel aujourd'hui) où il est recommandé de séparer votre "logique de programmation" (fonctions ou méthodes) de votre "vue" (le balisage HTML résultant). Cela conduit toujours à une base de code plus facile à gérer et il est en fait beaucoup plus facile à écrire. Cette expérience m'a incité à proposer une solution similaire lors du développement de plugins pour WordPress! Ce n'est pas très chic - c'est juste un petit "assistant" qui vous permettra de supprimer tous les extraits de code HTML et les "échappements" gênants de vos fonctions et de les placer en toute sécurité dans leur propre fichier "modèle".

J'espère donc que ce didacticiel vous intéressera et sans plus attendre, commençons!


Étape 1 Comprendre ce que nous allons améliorer

Commençons ce didacticiel en examinant exactement ce que nous allons améliorer.

Il est très courant de voir quelque chose comme ceci dans un plugin: (cet extrait provient en fait d'un de mes propres tutoriels sur ce site: p)

Qu'est ce qui ne va pas avec ça?

Eh bien rien, vraiment. Mais cela pourrait être plus propre, plus facile à faire évoluer et à maintenir!

En partant du haut vers le bas, nous pouvons voir que tous dans une seule fonction nous sommes:

  1. Interroger la base de données pour les publications d'un certain type
  2. Assigner une chaîne HTML à une variable
  3. Effectuer une boucle et concaténer d'autres balises dans la chaîne
  4. Renvoyer la chaîne construite

Maintenant, vous pouvez très bien regarder cela et penser "C'est un gros problème! Ce n'est que quelques lignes de HTML, quel est le problème?" À certains égards, vous avez bien le droit de penser de la sorte. Mais rappelez-vous, il n’ya que 17 lignes de code pour le moment - que se passe-t-il lorsque vous développez / améliorez le plugin? Que se passe-t-il lorsque votre plugin atteint 50/100/1000 lignes de code (ou plus!). Serez-vous toujours heureux d'avoir des chaînes HTML dispersées autour de votre fonction à différents endroits? Que se passe-t-il lorsque vous souhaitez générer du code HTML nécessitant une "échappatoire" gênante pour fonctionner correctement dans votre code PHP?

Espérons que vous puissiez constater que cette approche de création et de sortie de balises HTML peut devenir très problématique! Sans compter qu'il devient très difficile de maintenir et d'améliorer le code HTML lorsqu'il est dispersé.

Donc, avec tout cela à l’esprit, j’ai décidé de changer votre façon de penser la sortie HTML dans WordPress. Pour toujours.


Étape 2 Construire le plugin View Renderer

Ok, commençons à craquer avec ça.

Créer les fichiers et dossiers

  1. Créez un nouveau dossier de plug-in appelé View
  2. Dans ce dossier, créez le fichier plugin view_renderer.php
  3. Maintenant, créez un fichier appelé View.php - Ce sera notre classe

Inclure la classe

Notre plugin est simple, il inclut simplement la classe View afin que nous puissions l’utiliser dans n’importe lequel de nos autres plugins.

Ok, maintenant que nous avons inclus la classe View, il est temps de la construire.

La classe de vue

Nous avons ici une classe appelée View avec une fonction statique unique appelée render (cela nous permettra d'utiliser la syntaxe View::render($template) de n'importe où dans nos plugins) et prend deux paramètres:

  1. $filePath - Le chemin d'accès au fichier de modèle. N'oubliez pas que nous allons conserver nos modèles dans le dossier View que nous avons créé précédemment.
  2. $viewData - Toutes les variables auxquelles nous aimerions avoir accès dans le modèle (beaucoup plus à ce sujet plus tard)

Copiez le code ci-dessous dans View.php:

Alors, qu'est-ce qui se passe exactement ici?

  1. Nous vérifions d’abord si la variable $viewData a une valeur (c’est-à-dire avons-nous envoyé quelque chose à utiliser dans le modèle?). Si c'est le cas, nous extrayons le contenu (plus sur cela plus tard)

  2. Ensuite, nous utilisons le tampon de sortie de PHP. Cela nous permet d'analyser un fichier PHP et d'enregistrer le contenu dans une variable

  3. Finalement on retourne la ficelle

Remarque: N'oubliez pas d'activer le plugin maintenant à partir du panneau d'administration

Cela semble assez simple hein? Exactement! Mais si cela semble être une simple petite fonction très simple, cela nous offre le luxe de pouvoir écrire nos plugins de manière super organisée, évolutive et maintenable. S'il vous plaît, permettez-moi de démontrer ...


Étape 3: un exemple concret

Créons un plugin simple appelé Slider

** Remarque: Ceci est uniquement à des fins de démonstration. N'hésitez pas à utiliser votre propre plugin ici.

  1. Créez un dossier appelé Slider
  2. Dans ce dossier, créez un fichier nommé Slider.php.
  3. Copiez le code ci-dessous dans Slider.php

Ajouter un shortcode

OK, nous allons maintenant ajouter un shortcode qui récupérera les 5 derniers articles et les affichera dans une liste avec le titre et le contenu. (Par souci de brièveté, nous ajouterons notre classe de plug-ins et nos crochets d'action dans le même fichier de plug-in, mais veuillez ne pas le faire dans la "vie réelle": p)

Cela nous permettra d’utiliser simplement [slider] dans n’importe quel article / page et le résultat de Slider::display()

Ajouter la classe Slider et la méthode display()

Obtenez les 5 derniers messages.

Nous avons maintenant un tableau d'objets post et nous sommes prêts à construire notre code HTML en les parcourant en boucle. Mais nous n'allons pas simplement commencer à insérer des chaînes HTML dans notre fonction ici! Au lieu de cela, nous allons passer le tableau d'objets à un fichier de modèle et obtenir tout le code HTML généré hors du danger.

Créer le modèle

  1. Créez un dossier appelé templates
  2. Dans ce dossier, créez un fichier nommé 01.template.php.

Ce modèle contiendra l’ensemble de notre balisage et nous permettra d’accéder plus tard aux données que nous lui enverrons.

Envoi de données au modèle

Chaque fois que nous souhaitons utiliser des variables dans nos modèles, nous pouvons simplement les envoyer en définissant une valeur dans le tableau $viewData. Toute personne familiarisée avec l'utilisation des frameworks MVC se sentira très à l'aise avec cette approche.

La clé de tableau ici ('posts') est importante car c'est ainsi que nous nous référerons aux données du modèle. (Vous pouvez appeler cela comme bon vous semble, mais tenez-vous-en à quelque chose qui a du sens.)

Construire le modèle

Ok, nous avons donc cherché à récupérer les 5 derniers articles et à envoyer ce tableau d'objets au modèle. Il est maintenant temps d'étoffer le fichier modèle.

Ah! Est-ce que ça fait du bien d'avoir tout ce balisage dans son propre fichier, loin de notre logique de récupération des données et de programmation? Génial, je sais! La partie la plus importante de cette approche est que nous n’accédons jamais aux données à partir de variables du modèle. Toute la «logique» doit être effectuée dans la méthode qui appelle le modèle. Cela conduit à un très bon flux de travail car vous avez une séparation complète des préoccupations.

Imaginez à quel point ce sera facile lorsque vous serez prêt à utiliser ce plugin. Plus de concaténation de chaînes et de caractères d'échappement dans les fonctions.

Renvoi du modèle rendu

Ok, nous avons vu tous les composants, voyons comment tout cela s’allonge pour nous permettre de restituer un modèle et d’obtenir une chaîne (nous pourrons ensuite revenir à notre shortcode):

  1. Nous devons d’abord stocker une référence à notre modèle dans une propriété statique
  2. Ensuite, nous devons vérifier que la classe View existe
  3. Ensuite, nous générons le chemin complet vers notre fichier de modèle en saisissant une référence au répertoire du plugin actuel et en concaténant notre propriété statique $template
  4. Enfin, nous appelons notre méthode View::render() et lui passons les deux paramètres nécessaires

Dans ce cas, nous renvoyons le résultat du modèle rendu, car c'est ainsi que fonctionnent les codes courts. Toutefois, si vous souhaitez plutôt afficher les résultats en écho (par exemple, lorsque vous créez une page d'administration, le rappel attend l'impression de votre sortie directement), remplacez simplement return par echo.

La méthode display() au complet

J'espère que vous pourrez apprécier le niveau d'organisation que cette approche vous permettra! Désormais, votre fonction d’affichage est uniquement chargée de collecter les données dont elle a besoin et de renvoyer le résultat du modèle rendu.


Aller plus loin

Notre exemple ci-dessus est à peu près aussi basique que possible. Malgré tout, le flux de travail reste considérablement amélioré. Voyons maintenant un autre exemple qui montre à quel point cela peut être utile.

Supposons, par exemple, que votre plugin utilise une méta-boîte personnalisée. Pour ce faire, il faudrait:

  1. Ajouter une fonction constructeur à la classe Slider
  2. Ajouter une méthode pour ajouter le metabox à chaque message
  3. Ajouter une méthode de rappel pour restituer le code HTML de la boîte méta
  4. Ajoutez le hook approprié dans le fichier plugin pour instancier la classe uniquement lors de l'ajout / la modification de publications
  5. Enfin, nous ajouterions un fichier modèle comme nous l’avions fait précédemment et nous l’ajouterions comme propriété au début de la classe

Jetez un coup d'œil à la méthode render_meta_box_content ici. C'est l'occasion idéale d'utiliser le moteur de rendu de vue! Imaginez un exemple plus réaliste comme celui-ci:

Urg! Bien sûr, le travail est fait, mais c'est tellement difficile de le faire de cette façon! Et si nous utilisions notre moteur de rendu de vue à la place.

Et dans le fichier modèle:

Cela peut sembler être un très petit avantage dans cet exemple. Mais croyez-moi, si vous gardez vos préoccupations séparées de la sorte, vous deviendrez rapidement un meilleur développeur WordPress.


Conclusion

Je pense que maintenant vous avez probablement une bonne compréhension de ce que nous essayons de réaliser ici et je vous encourage à utiliser cette technique lors de la création de plugins à l'avenir. J'espère que vous constaterez que la «séparation des préoccupations» vous profite.

Notes du tutoriel:

  • Bien que nous ayons transformé View Renderer en un plugin, vous pouvez facilement l'ajouter à des plugins existants. Cela supprimera l'étape supplémentaire de devoir s'assurer que le plugin est activé avant de l'utiliser n'importe où.
  • Vous n'êtes pas limité aux cas d'utilisation expliqués dans ce didacticiel, il peut être utilisé partout où vous auriez normalement généré du HTML (pourquoi ne pas utiliser un fichier modèle pour générer du code JavaScript «en ligne»? Ou des règles CSS spécifiques basées sur options extraites de la base de données?)

Je serais intéressé de connaître les utilisations que vous avez trouvées pour cette technique, alors partagez-les dans les commentaires :)

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.