✅ Notizie, temi, plugin WEB e WordPress. Qui condividiamo suggerimenti e le migliori soluzioni per siti web.

Modelli e logica condizionale con OOP in WordPress

8

La creazione di modelli sta diventando sempre più comune in WordPress e la considero una buona cosa.

Ma ciò non significa che non ci siano progetti che gestiamo che utilizzano un approccio più tradizionale alla visualizzazione di modelli o parziali. Inoltre, non significa nemmeno che siamo esenti dal mantenere basi di codice che utilizzano codice che non utilizza un motore di modelli.

Anche se penso che la creazione di modelli sia buona, non penso che sia sempre necessaria. Questo è il contenuto per un altro post, però.

Invece, voglio esaminare il processo di utilizzo della logica condizionale se visualizzare o meno un parziale all’interno di un modello e farlo utilizzando la programmazione orientata agli oggetti.

Modellistica e logica condizionale con OOP

Per fare ciò, assumiamo quanto segue:

  1. Abbiamo un plugin che dipende da un altro plugin per una funzione.
  2. Il secondo plugin è facoltativo.
  3. Se non è presente, visualizzeremo un avviso. Se è presente, visualizzeremo un parziale.

Abbastanza diretto, giusto?

L’unica cosa da notare è che tutta questa logica verrà mantenuta all’interno del plugin principale (ovvero quello che verificherà la presenza dell’altro plugin).

1 La logica condizionale del modello

La prima cosa da fare è avere una funzione che verificherà la presenza del plugin secondario. La ragione di ciò è perché il modello sta facendo per assomigliare a questo:

E poi il parziale potrebbe assomigliare a questo (dipende dalla tua implementazione):

A causa del modo in cui i modelli sono inclusi in WordPress, la funzione vivrà all’interno di una classe e la classe verificherà la presenza del plug-in.

Se usi uno sniffer di codice, probabilmente attiverà un avviso che il metodo non è usato, ma il metodo è usato, è solo usato in un file modello. Nota in una classe. Tutto ciò per dire, alcuni dei nostri sniffer non sono così intelligenti. Ancora.

2 Il codice lato server del plug-in

Una volta che hai un’idea generale su come funzionerà, è il momento di scrivere il codice nella tua classe.

Ricorda, questa è una funzione semplice: deve solo verificare la presenza di un plug-in. Puoi farlo in alcuni modi, ma il più comune potrebbe essere usare la funzione API is_active_plugin .

Nota che quando usi questa funzione, si basa sull’idea che conosci il nome del plugin che stai usando. In caso contrario, ci sono altri modi, ma questo esula dallo scopo di questo post.

Ad ogni modo, poiché la logica è condizionale, deve restituire un valore booleano, ed è esattamente ciò che fa la funzione API sopra. Quindi la funzione lato server può assomigliare a questa:

E poiché il codice del modello chiama questa funzione (che vedi sopra), determinerà se deve mostrare un parziale o meno.

Abbastanza facile

Per alcuni, questa è roba davvero semplice; per altri, è un approccio completamente diverso in quanto si occupa di una maggiore separazione delle preoccupazioni.

E mentre continuo a lavorare su OOP Fundamentals con i membri del sito, penso che sia importante anche condividere alcune delle migliori pratiche con coloro che potrebbero non essere membri ma desiderosi di scrivere codice più organizzato.

Fonte di registrazione: tommcfarlin.com

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More