Widget WordPress: un approccio orientato agli oggetti
Anni fa, ho creato WordPress Widget Boilerplate con l’obiettivo di essere il seguente:
Un boilerplate organizzato e manutenibile per la creazione di widget utilizzando le migliori pratiche di WordPress.
Da allora, non è cambiato molto per quanto riguarda l’ API Widgets (che esamineremo più avanti in questo post), ma quelle che considero "best practices" sono cambiate. Inoltre, il grado in cui penso che questa API sia una solida esempio di programmazione introduttiva orientata agli oggetti in WordPress è alto.
Non è perché utilizza molti principi orientati agli oggetti, non è perché utilizza standard moderni (almeno per quanto riguarda il moderno PHP), ma perché usa alcune cose che ci aiutano a riconoscerne alcune, diciamo, segnali riguardanti la programmazione orientata agli oggetti in WordPress.
E questo è qualcosa che non dovrebbe essere sottovalutato: se stai cercando esempi di programmazione orientata agli oggetti in WordPress, cerca le API che la utilizzino.
Inoltre, se stai cercando modi per valutare il tuo livello di valutazione di un pezzo di codice (per non parlare di una base di codice) per l’uso di classi e alcune delle funzionalità più avanzate di OOP, allora perché non avere una sorta di di una cartina di tornasole per vedere come stai?
E l’API Widgets fa proprio questo.
Widget WordPress: un’introduzione
Quindi, in una serie più piccola della mia precedente, miro a guardare l’API Widgets e fare alcune cose:
- mostrarti lo scheletro di base di un widget e perché è orientato agli oggetti,
- discutere quali cose dovresti essere in grado di notare e perché,
- prima aggiorna il Widget Boilerplate direttamente su questo sito e poi invialo a GitHub,
- costruire un widget utilizzando l’API con il boilerplate come base per il nostro lavoro.
E in questo post, inizieremo con il primo punto sopra.
Ma prima…
Prima di entrare in questo post, ti consiglio di leggere i seguenti post:
- Due pilastri della programmazione orientata agli oggetti: parte 1 di 2
- Due pilastri della programmazione orientata agli oggetti: parte 2 di 2
- Classi astratte, parte 1 – Comportamento astratto
- Classi astratte, parte 2 – Classi astratte e interfacce
Una volta terminato (o se ritieni di avere già una comprensione degli argomenti), allora siamo pronti per partire.
[restrict paid="true”]
Le basi dell’API dei widget
Se leggi la pagina del manuale su Widget, vedrai molti contenuti. Questa è una buona cosa, ma non è sempre la mossa migliore quando cerchi di distillare i contenuti per un pubblico come te quando cerchi consigli pratici e orientati agli oggetti.
Quindi sceglierò le parti rilevanti dalla documentazione dell’API e quindi la applicherò al codice che ci viene fornito.
Cos’è un widget?
Penso che la maggior parte di noi che lavora con WordPress sappia cos’è un widget, ma è importante definire il termine, quindi stiamo tutti lavorando sulla stessa idea. Il manuale recita:
Un widget è un oggetto PHP che genera dell’HTML. Lo stesso tipo di widget può essere utilizzato più volte sulla stessa pagina (es. il widget di testo). I widget possono salvare i dati nel database (nella tabella delle opzioni).
Con questo in atto, diamo un’occhiata al codice di un widget personalizzato, almeno uno stub di esso, e vediamo cosa possiamo ricavare per quanto riguarda la sua natura orientata agli oggetti.
La classe dei widget
Prima ancora di guardare il codice, sappiamo che ci sarà un certo livello di programmazione orientata agli oggetti semplicemente perché la documentazione ci dice di fare tre cose:
- Crea la classe del tuo widget estendendo la classe WP_Widget standard e alcune delle sue funzioni.
- Registra il tuo widget in modo che sia reso disponibile nella schermata Widget.
- Assicurati che il tuo tema abbia almeno un’area widget in cui aggiungere i widget.
In questo post, mi concentrerò sul primo punto (anche se alla fine arriveremo a come introdurre i nostri widget in un tema prima che la serie sia finita).
Quindi definiamo il codice come è presentato nella documentazione e parliamo di ciò che possiamo imparare da esso:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Innanzitutto, notiamo che sebbene abbiamo definito una classe (che possiamo nominare come vogliamo, a modo mio), deve estendere WP_Widget. Ciò significa che nel core di WordPress esiste una classe WP_Widget. È possibile visualizzare un’analisi ben organizzata del codice sorgente in questa pagina.
In secondo luogo, la parola chiave extends indica che stiamo usando l’ ereditarietà PHP, che è un pilastro fondamentale della programmazione orientata agli oggetti.
Terzo, ci sono quattro funzioni che dobbiamo implementare, due delle quali richiedono argomenti. Le funzioni che dobbiamo implementare sono le seguenti:
- __construct() che è il costruttore di classi di base. Qui è dove dovremo assicurarci che il costruttore della classe genitore sia chiamato, se ce n’è uno, e quindi inizializzare qualsiasi proprietà riteniamo necessaria per il nostro widget. Daremo un’occhiata a questo più avanti nella serie.
- widget() è responsabile dell’output dei contenuti del widget che l’utente fornisce utilizzando l’interfaccia nell’area amministrativa. Accetta due parametri: $args e $instance. Il parametro $args è l’informazione da visualizzare nella pagina, e $instance è un riferimento all’istanza del widget (poiché è possibile eseguire il rendering di più widget su una pagina).
- form() mostra l’interfaccia amministrativa con cui l’utente interagisce per guidare l’output sul front-end del sito. Richiede anche l’ argomento $istanza in modo che le informazioni fornite siano per il widget effettivo con cui l’utente sta lavorando (rispetto a tutte le istanze del widget).
- update() viene utilizzato per salvare i valori nell’istanza corrente del widget. Accetta due argomenti. Il primo è la nuova istanza del widget con gli aggiornamenti dei valori forniti dall’utente (pensate di aggiornare il valore di un widget di testo attivo) e il secondo argomento è quello della vecchia istanza del widget o forse dell’istanza precedente o forse " l’istanza che conteneva i valori precedenti.
Queste quattro funzioni sono necessarie per essere implementate come parte dell’API Widget, come parte delle funzioni ereditarie dall’interfaccia estesa e per produrre le funzionalità di base di un widget.
Ciò non significa che non sia possibile aggiungere altro, ma in un buon modo orientato agli oggetti, sarebbe probabilmente meglio relegare quel comportamento in altre classi. Ma daremo un’occhiata a farlo più avanti nella serie quando creeremo il nostro widget.
Quali sono i punti chiave da asporto?
Per essere sicuro di essere chiaro su cosa si capirebbe da questo post, è il seguente:
- L’API dei widget è orientata agli oggetti. Non è solo orientato agli oggetti perché usa una classe (anche se questo è certamente un buon punto di partenza), ma anche perché eredita le funzionalità integrate in una classe base preesistente.
- Ogni volta che ereditiamo il comportamento da una classe base o da una classe genitore, otteniamo gratuitamente funzionalità pre-sviluppate. È davvero una cosa grandiosa della programmazione orientata agli oggetti perché ci consente di concentrarci in modo specifico sulla logica di programmazione che desideriamo implementare.
Immagina per un momento di voler sviluppare un widget, ma ogni volta che lo fai, devi scrivere tutte le funzionalità per gli hook in WordPress per fare tutte le stesse, ripetitive funzionalità standard.
È qui che entrano in gioco l’ereditarietà e la programmazione orientata agli oggetti. Il codice ripetitivo viene astratto in una classe base, quindi viene scritto solo una volta e quindi il codice su cui vogliamo concentrarci viene lasciato a noi per l’implementazione.
Tutto quanto sopra è ciò che dovrebbe essere compreso quando si legge questo passaggio iniziale al codice sorgente per un’API di base orientata agli oggetti in WordPress.
Qual è il prossimo?
Nel prossimo post di questa serie, esamineremo la natura orientata agli oggetti dell’API Widgets e quali cose dovresti essere in grado di rilevare immediatamente leggendo il codice.
Questo perché è importante riconoscere in pratica determinati principi orientati agli oggetti e questo è un buon modo per valutare se sei in grado di farlo o meno. Se lo sei, fantastico! Quindi continuerà ad aiutare a sviluppare quel muscolo. In caso contrario, non preoccuparti: ti aiuta comunque a sviluppare quel muscolo.
E ti servirà bene mentre continuiamo a muoverci sempre di più nello sviluppo di WordPress orientato agli oggetti attraverso mezzi pratici.
La teoria necessaria è stata coperta. Quindi iniziamo a metterlo in pratica.