Miglioramento del flusso di lavoro - Separa il mark-up dalla tua logica!

In questo tutorial illustrerò una tecnica che ti consente di utilizzare un file modello per tutte le tue esigenze HTML! Non avrai più bisogno di "echo" le stringhe all'interno delle tue funzioni, o ti preoccuperai di inserire e uscire da PHP solo per generare dei markup.

Ho passato molti anni a utilizzare i framework MVC (come Zend e al giorno d'oggi Laravel), dove è una buona pratica separare la 'logica di programmazione' (funzioni o metodi) dalla 'vista' (il markup HTML risultante). Questo sempre porta a una base di codice più manutenibile ed è in realtà molto più facile da scrivere. Avere questo background mi ha spinto a trovare una soluzione simile nello sviluppo di plugin per WordPress! Non è niente di speciale: è solo un piccolo "aiuto" che ti permetterà di rimuovere tutti gli snippet HTML e di "scappare" dalle tue funzioni e metterli al sicuro nel loro file "modello".

Quindi, spero che questo tutorial ti sembri interessante e, senza ulteriori indugi, iniziamo!


Passo 1 Capire cosa stiamo andando a migliorare

Diamo un calcio a questo tutorial dando un'occhiata esattamente a ciò che stiamo per migliorare.

È molto comune vedere qualcosa di simile all'interno di un plugin: (questo frammento proviene in realtà da uno dei miei tutorial su questo sito: p)

 add_shortcode ('faq', function () $ posts = get_posts (array (// Ottieni le FAQ Custom Post Type 'numberposts' => 10, 'orderby' => 'menu_order', 'order' => 'ASC', 'post_type' => 'faq',)); $ faq = '
'; // Apri il contenitore foreach ($ post come $ post) // Genera il markup per ogni domanda $ faq. = Sprintf (('

% 1 $ s

'), $ post-> post_title, wpautop ($ post-> post_content)); $ faq. = '
'; // Chiudi il contenitore restituisce $ faq; // Restituisce l'HTML. );

Che cosa c'è che non va?

Beh niente, davvero. Ma potrebbe essere più pulito, più facile da scalare e più manutenibile!

Correndo dall'alto verso il basso, possiamo vedere che tutti all'interno di una singola funzione siamo:

  1. Interrogare il database per i post di un certo tipo
  2. Assegnazione di una stringa HTML a una variabile
  3. Esecuzione di un ciclo e concatenazione di ulteriori markup alla stringa
  4. Restituire la stringa creata

Ora puoi benissimo guardare questo e pensare "Grande affare! Sono solo alcune righe di HTML, qual è il problema?" Per certi versi sei benissimo nei tuoi diritti di pensare in questo modo. Ma ricorda, al momento ci sono solo 17 linee di codice - cosa succede quando espandi / migliora il plugin? Cosa succede quando il tuo plug-in cresce a 50/100/1000 righe di codice (o più!). Sarai comunque contento di avere stringhe HTML puntate sulla tua funzione in vari luoghi? Cosa succede quando si vuole esportare un codice HTML che necessita di qualche 'scappatoia' per funzionare correttamente all'interno del codice PHP?

Spero che questo approccio alla creazione e alla pubblicazione di HTML Markup possa diventare molto problematico! Senza contare che diventa molto difficile mantenere e migliorare l'HTML quando è sparpagliato.

Quindi, con tutto questo in mente, mi sono preso la briga di cambiare il modo in cui pensi di emettere l'HTML in WordPress. Per sempre.


Passaggio 2 Creazione del plug-in Viewer di rendering

Ok, andiamo a fare i conti con questo.

Crea i file e le cartelle

  1. Crea una nuova cartella di plugin chiamata vista
  2. All'interno di quella cartella, crea il file del plugin view_renderer.php
  3. Ora crea un file chiamato view.php - Questa sarà la nostra classe

Includi la classe

Il nostro plugin è semplice, include solo il vista classe in modo che possiamo usarlo in uno qualsiasi dei nostri altri plugin.

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

Ok, ora che abbiamo incluso il vista classe, è ora di costruirlo.

La classe View

Qui abbiamo una classe chiamata vista con una singola funzione statica chiamata rendere (questo ci permetterà di usare la sintassi Visualizza :: render ($ template) da qualsiasi punto all'interno dei nostri plugin) e richiede due parametri:

  1. $ filePath - Il percorso del file di modello. Non dimenticare che terremo i nostri modelli all'interno del vista cartella che abbiamo creato in precedenza
  2. $ Viewdata - Qualsiasi variabile a cui vorremmo avere accesso all'interno del modello (molto più su questo più avanti)

Copia il codice qui sotto in view.php:

 

Quindi, cosa sta succedendo esattamente qui??

  1. Prima di tutto stiamo controllando se il $ Viewdata varible ha un valore (cioè abbiamo inviato qualcosa da utilizzare nel modello?). Se lo fa, estraiamo il contenuto (ne parleremo più avanti)

  2. Quindi stiamo facendo uso del buffer di output di PHP. Ci consente di analizzare un file PHP e salvare il contenuto in una variabile

  3. Alla fine restituiamo la stringa

Nota: non dimenticare di attivare il plug-in ora dal pannello di amministrazione

Sembra piuttosto semplice eh? Esattamente! Ma mentre sembra essere solo una piccola funzione molto semplice, in realtà ci offre il lusso di poter scrivere i nostri plugin in modo super organizzato, scalabile e manutenibile. Per favore, permettimi di dimostrare ...


Passo 3 Un esempio del mondo reale

Creiamo un semplice plugin chiamato Slider

** Nota: questo è solo a scopo dimostrativo. Sentiti libero di usare il tuo plugin qui.

  1. Crea una cartella chiamata Slider
  2. In quella cartella, crea un file chiamato Slider.php
  3. Copia il codice qui sotto in Slider.php
 

Aggiungi uno shortcode

OK, ora aggiungeremo uno shortcode che recupererà gli ultimi 5 post e li visualizzerà in un elenco con il titolo e il contenuto. (Per motivi di brevità, aggiungeremo la nostra classe di plugin e i nostri hook di azione nello stesso file di estensione, ma per favore non farlo nella "vita reale": p)

 / ** * Aggiungi lo Shortcode (PHP 5.3 e successivi) * / add_shortcode ('slider', function () return Slider :: display (););

Questo ci permetterà semplicemente di usarlo [Cursore] in qualsiasi post / pagina e verrà visualizzato il risultato di Slider :: display ()

Aggiungi la classe di slider e display() Metodo

 class Slider public static function display () // Restituisci HTML QUI. 

Ricevi gli ultimi 5 post.

 / * * Ottieni gli ultimi 5 post * / public static function display () $ posts = get_posts (array ('numberposts' => 5)); 

Ora abbiamo una serie di inviare oggetti e siamo pronti a costruire il nostro codice HTML scorrendoli tra loro. Ma non stiamo per iniziare semplicemente a inserire stringhe HTML nella nostra funzione qui! Invece, passeremo la matrice di oggetti a un file di modello e avremo tutto il codice HTML generato in modo dannoso.

Crea il modello

  1. Crea una cartella chiamata modelli
  2. All'interno di quella cartella, crea un file chiamato 01.template.php

Questo modello manterrà tutti i nostri markup e ci permetterà di accedere ai dati noi inviare ad esso più tardi.

Invio di dati al modello

Ogni volta che vogliamo utilizzare qualsiasi variabile all'interno dei nostri modelli, possiamo semplicemente inviare loro impostando un valore nel $ Viewdata array. Chiunque abbia familiarità con l'utilizzo dei framework MVC si sentirà a proprio agio con questo approccio.

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

L'array chiave Qui ('messaggi') è importante perché è così che faremo riferimento ai dati all'interno del modello. (Puoi chiamarlo come preferisci, ma attenersi a qualcosa che abbia senso).

Costruire il modello

Ok, quindi abbiamo visto come recuperare gli ultimi 5 post e come inviare quella matrice di oggetti al modello, ora è il momento di arricchire il file modello.

 
  • post_title?>

    post_content?>

Ah! Quanto è bello avere tutto quel markup nel proprio file separato, lontano dalla nostra logica di recupero e programmazione dei dati? Grande, lo so! La parte più importante di questo approccio è che stiamo sempre e solo "accedendo" ai dati dalle variabili all'interno del modello. Tutta la 'logica' dovrebbe essere fatta all'interno del metodo che chiama il modello. Questo porta a un flusso di lavoro molto bello in quanto hai una completa separazione delle preoccupazioni.

Immagina quanto sarà facile ora quando sarai pronto per costruire su questo plugin. Niente più concatenazione di stringhe e caratteri di escape all'interno delle funzioni.

Restituzione del modello renderizzato

Ok, abbiamo visto tutte le parti dei componenti, vediamo come si combina tutto per permetterci di eseguire il rendering di un modello e ottenere una stringa indietro (che possiamo quindi tornare al nostro shortcode):

  1. Per prima cosa dobbiamo memorizzare un riferimento al nostro modello in una proprietà statica
  2. Quindi dobbiamo controllare che il vista la classe esiste
  3. Quindi generiamo il percorso completo del nostro file di modello acquisendo un riferimento alla directory corrente del plugin e concatenando la nostra proprietà statica $ template
  4. Infine, chiamiamo il nostro Vista :: render () metodo e passare i due parametri necessari

In questo caso, noi ritorno il risultato del modello renderizzato perché è così shortcodes lavoro. Ma se tu avessi bisogno di eco i risultati invece (ad esempio, quando crei una pagina di amministrazione, il callback si aspetta che l'output venga stampato direttamente), quindi sostituisce semplicemente ritorno con eco.

Il display() Metodo in pieno

 class Slider static $ template = '/templates/01.template.php'; display public function function () if (class_exists ('View')) // Ricevi gli ultimi 5 post $ posts = get_posts (array ('numberposts' => 5)); // Imposta visualizzazione dati $ viewData = array ('posts' => $ post); // Ottieni il percorso completo per il file del modello. $ templatePath = dirname (__FILE__). statica :: $ template; // Restituisce il rendering HTML reso View :: render ($ templatePath, $ viewData);  else return "Stai tentando di eseguire il rendering di un modello, ma non siamo in grado di trovare la classe View"; 

Spero che tu possa apprezzare il livello di organizzazione che questo approccio ti permetterà! Adesso tuo display la funzione è responsabile solo della raccolta dei dati di cui ha bisogno e della restituzione del risultato del modello renderizzato.


Prendendo ulteriormente

Il nostro esempio sopra è di base come diventa. Anche così, è ancora un flusso di lavoro notevolmente migliorato. Ora diamo un'occhiata a un altro esempio che mostra quanto possa essere utile.

Supponiamo, ad esempio, che il tuo plug-in faccia uso di una meta-box personalizzata. Per farlo dovremmo:

  1. Aggiungi una funzione di costruzione al Slider classe
  2. Aggiungi un metodo per aggiungere il metabox ad ogni post
  3. Aggiungi un metodo di callback per il rendering dell'HTML per la meta-box
  4. Aggiungi il gancio appropriato nel file del plugin per istanziare la classe solo quando aggiungi / modifichi i post
  5. Infine, dovremmo aggiungere un file modello come abbiamo fatto in precedenza e aggiungerlo come una proprietà all'inizio della classe
 class Slider static $ metaBox = '/templates/metabox.template.php'; funzione pubblica __construct () add_action ('add_meta_boxes', array ($ this, 'add_some_meta_box'));  / ** * Aggiunge il contenitore del meta box * / public function add_some_meta_box () add_meta_box ('some_meta_box_name', 'Alcuni Metabox Headline', array ($ this, 'rendering_meta_box_content'), 'post', 'advanced', ' alto ',);  / ** * Rendering del contenuto della Meta Box * / public function render_meta_box_content () / ** Dal Codex ** / echo '

TEST OUTPUT - questo viene reso all'interno della meta-box.

'; // class // aggiunge la funzione hook action call_Slider () return new Slider (); if (is_admin ()) add_action ('load-post.php', 'call_Slider');

Dai un'occhiata al render_meta_box_content metodo lì. È l'occasione perfetta per usare Viewer! Immagina un esempio più realistico come questo:

 / ** * Render contenuto Meta Box * / public function render_meta_box_content ($ post) $ name = get_post_meta ($ post-> ID, "nome"); $ fieldName = static :: $ fieldName; eco '

Il tuo nome:

'; eco ''; eco ''; eco '';

Urg! Certo, ha fatto il lavoro, ma è così difficile farlo in questo modo! Che ne dici invece di utilizzare il nostro View Renderer.

 / ** * Rendering contenuto Meta Box * / public function render_meta_box_content ($ post) $ viewData = array ('name' => get_post_meta ($ post-> ID, 'nome'), 'campo' => statico :: $ fieldName); $ templatePath = dirname (__FILE__). statica :: $ METABOX; echo View :: render ($ templatePath, $ viewData); 

E nel file di modello:

 

Il tuo nome:

Potrebbe sembrare solo un piccolo vantaggio in questo esempio. Ma credimi, se tieni le tue preoccupazioni separate in questo modo, diventerai uno sviluppatore WordPress molto migliore abbastanza rapidamente.


Conclusione

Penso che ora probabilmente hai una buona comprensione di ciò che stiamo cercando di ottenere qui e ti esorto a provare a utilizzare questa tecnica quando crei plug-in in futuro. Spero che troverai la "separazione delle preoccupazioni" a tuo vantaggio.

Note dell'esercitazione:

  • Sebbene abbiamo reso View Renderer in un plug-in da solo, puoi facilmente aggiungerlo semplicemente ai plugin esistenti. Questo rimuoverà il passo extra di dover garantire che il plugin sia attivato prima di utilizzarlo ovunque.
  • Non sei limitato ai casi d'uso spiegati in questo tutorial, può essere usato ovunque tu normalmente generi l'HTML (che ne dici di usare un file modello per generare qualche JavaScript 'in-line' o di alcune regole CSS specifiche basate su opzioni recuperate dal database?)

Sarei interessato a sapere quali usi hai trovato per questa tecnica, quindi per favore condividi i commenti :)