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

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 ou non de PHP simplement pour afficher des balises.

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). Ce toujours conduit à 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 fragments HTML et les "échappements" gênants de vos fonctions et de les placer en toute sécurité dans leur propre fichier "modèle".

Donc, j'espère que ce tutoriel vous intéressera et sans plus tarder, commençons!


Étape 1 Comprendre ce que nous allons améliorer

Commençons ce tutoriel en jetant un coup d'oeil à 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)

 add_shortcode ('faq', function () $ posts = get_posts (array (// Obtient la FAQ Type de message personnalisé. 'numberposts' => 10, 'orderby' => 'menu_order', 'order' => 'ASC', 'post_type' => 'faq',)); $ faq = '
'; // Ouvre le conteneur foreach ($ posts en tant que $ post) // Génère le balisage pour chaque question $ faq. = Sprintf (('

% 1 $ s

'), $ post-> post_title, wpautop ($ post-> post_content)); $ faq. = '
'; // Ferme le conteneur return $ faq; // retourne le HTML. );

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

Eh bien rien, vraiment. Mais il pourrait être plus propre, plus facile à redimensionner 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 voulez 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 simplement 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 plugin appelé Vue
  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 ne comprend que le Vue classe afin que nous puissions l'utiliser dans l'un de nos autres plugins.

 / * view_renderer.php * / include ('View.php');

Ok, maintenant que nous avons inclus le Vue classe, il est temps de le construire.

La classe de vue

Ici nous avons une classe appelée Vue avec une seule fonction statique appelée rendre (cela nous permettra d'utiliser la syntaxe View :: render ($ template) de n'importe où dans nos plugins) et il faut 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 Vue dossier que nous avons créé plus tôt
  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. Tout d’abord, nous vérifions si le $ viewData varible 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 bien que 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é Curseur

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

  1. Créez un dossier appelé Curseur
  2. Dans ce dossier, créez un fichier appelé 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)

 / ** * Ajouter le Shortcode (PHP 5.3 et supérieur) * / add_shortcode ('slider', function () return Slider :: display (););

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

Ajouter la classe de curseur et afficher() Méthode

 class Slider public static function display () // Retourne HTML ICI. 

Obtenez les 5 derniers messages.

 / * * Récupère les 5 derniers posts * / fonction publique statique display () $ posts = get_posts (array ('numberposts' => 5)); 

Maintenant, nous avons un tableau de poster objets et nous sommes prêts à construire notre code HTML en les parcourant. 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é des modèles
  2. Dans ce dossier, créez un fichier appelé 01.template.php

Ce modèle contiendra l’ensemble de nos balises et nous permettra d’accéder aux données que nous avons. envoyer à plus tard.

Envoi de données au modèle

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

 $ viewData = array ('posts' => $ posts);

Le tableau clé ici ('des postes') est important 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 de logique.)

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..

 
  • post_title?>

    post_content?>

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 le Vue la classe 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é static $ template
  4. Enfin, nous appelons notre Voir :: render () méthode et passez les deux paramètres nécessaires

Dans ce cas, nous revenir le résultat du modèle rendu parce que c'est ainsi codes courts travail. Mais si vous aviez besoin de écho les résultats à la place (par exemple, lorsque vous créez une page Admin, le rappel attend que votre sortie soit imprimée directement), puis remplacez simplement revenir avec écho.

le afficher() Méthode complète

 class Slider static $ template = '/templates/01.template.php'; Fonction statique publique display () if (class_exists ('View')) // Récupère les 5 derniers messages $ posts = get_posts (array ('numberposts' => 5)); // Définir la vue Données $ viewData = array ('posts' => $ posts); // Récupère le chemin complet du fichier de modèle. $ templatePath = dirname (__FILE__). static :: $ template; // Retourne le rendu HTML renvoyé View :: render ($ templatePath, $ viewData);  else return "Vous essayez de rendre un modèle, mais nous ne trouvons pas la classe de vue"; 

J'espère que vous pourrez apprécier le niveau d'organisation que cette approche vous permettra! Maintenant votre afficher La fonction est uniquement responsable de la collecte des données dont elle a besoin et du renvoi du 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 il peut être vraiment 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 Curseur classe
  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 en tant que propriété au début de la classe.
 class Slider static $ metaBox = '/templates/metabox.template.php'; fonction publique __construct () add_action ('add_meta_boxes', array ($ this, 'add_some_meta_box'));  / ** * Ajoute le conteneur de méta-boîtes * / fonction publique add_some_meta_box () add_meta_box ('nom_du_champ_méta', 'certains titres de la boîte-méta', tableau ($ this, 'render_meta_box_content'), 'post', 'avancé' ',' haute', );  / ** * Rendre le contenu de la méta-boîte * / fonction publique render_meta_box_content () / ** à partir du Codex ** / echo '

TEST OUTPUT - ceci est rendu dans la boîte méta.

'; // classe // ajouter la fonction de crochet d'action call_Slider () return new Slider (); if (is_admin ()) add_action ('load-post.php', 'call_Slider');

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

 / ** * Rendu du contenu de la méta-boîte * / fonction publique render_meta_box_content ($ post) $ name = get_post_meta ($ post-> ID, "name"); $ fieldName = static :: $ fieldName; écho '

Votre nom:

'; écho ''; écho ''; écho '';

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 rendu de vue à la place.

 / ** * Rendu du contenu de la méta-boîte * / fonction publique render_meta_box_content ($ post) $ viewData = array ('name' => get_post_meta ($ post-> ID, 'name'), 'field' => static :: $ nom de domaine ); $ templatePath = dirname (__FILE__). static :: $ metabox; echo View :: render ($ templatePath, $ viewData); 

Et dans le fichier modèle:

 

Votre nom:

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 vivement à 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 :)