WordPress-koukkujen rekisteröinti toisella luokalla
Eilisessä postauksessa puhuin WordPress-laajennuksen rakentajista ja perusteluista sille, miksi koukkujen ei pitäisi olla rakentajassa.
Vaikka mainitsinkin useita tapoja käsitellä koukun rekisteröintiä, en vaivautunut menemään yksityiskohtiin kunkin strategian osalta. Minun mielestäni he ansaitsevat oman artikkelinsa tarjotakseen mahdollisimman paljon yksityiskohtia siitä, miten jotain asetetaan.
Esimerkiksi yksi jakamistani tavoista sanoi:
- WordPressillä on mahdollista luoda luokka, joka ylläpitää rekisteriä objekteista ja koukuista.
Toisin sanoen kyse on WordPress-koukkujen rekisteröinnistä käyttämällä oliolähtöistä lähestymistapaa kytkennän vähentämiseksi ja yhteenkuuluvuuden lisäämiseksi laajennuksen komponenttien välillä.
Mutta mitä se edes tarkoittaa? Mitä hyötyä siitä on, miten se asennetaan ja miten sitä käytetään?
WordPress-koukkujen rekisteröinti
Jos luet tätä, olet todennäköisesti perehtynyt WordPress- hook-järjestelmään, niiden käynnistysjärjestykseen ja siihen, kuinka funktio tai luokka voi rekisteröidä funktionsa WordPressiin, jotta ne voivat suorittaa mitä tahansa tarvitsemaansa työtä.
Ja näemme usein luokkien tekevän tämän yksin. Projektista riippuen teen sen itse. Niille, jotka eivät ole tuttuja, se näyttää yleensä tältä :
<?php
add_action( 'plugins_loaded', 'acme_start' );
/**
* Start the machine.
* https://www.youtube.com/watch?v=ysoMOefPyRs
*/
function acme_start() {
$plugin = new AcmeColumn();
}
Mutta kaikki tämä voidaan jakaa yhtenäisemmiksi luokiksi, jotta niille annetaan lopulta vielä vähemmän vastuuta (hyvä asia) ja vähennetään luokan tai luokkajoukon välistä yhteyttä WordPressin kanssa.
Esimerkki mallista, jonka aion purkaa tässä viestissä.
Tämän intuitiivisen vastakohtana on kuitenkin se, että se vaatii ainakin toisen luokan. Mutta näin se toimii.
Käyttöönotto
Tässä esimerkissä käytämme vain yksinkertaista luokkaa, joka rekisteröi tietyn tyyppisen toiminnon WordPressiin. Idea arkkitehtuurista toimii jotakuinkin näin:
- Siellä on pääluokka, jolla on toiminto, jonka haluamme liittää WordPressiin.
- Siellä on luokka, joka vastaa luokan funktion liittämisestä WordPressiin.
Tarpeeksi helppoa, eikö? Mutta tässä on saalis: luokka, joka vastaa tietyn luokan funktioiden rekisteröimisestä WordPressiin, on se kohta, joka vaatii suunnittelupäätöksen.
Kutsutaan ensin luokkaa HookRegistry, jotta voimme viitata siihen oikein. Kutsutaan seuraavaksi luokkaa funktioineen, joihin haluamme liittää AcmeColumn yksinkertaisesti edustamaan luokkaa, joka lisää uuden sarakkeen, sivun hallintapaneeliksi WordPressin hallinta-alueella.
Kun se on paikallaan, suunnittelupäätös tulee tähän:
- Pitäisikö HookRegisteryn tietää AcmeColumnista?
- Pitäisikö AcmeColumn tietää HookRegistrystä?
Tiedän, että on olemassa muitakin tapoja järjestää tämä ja on olemassa myös strategioita tämän käsittelemiseksi (kuten ohjauksen kääntäminen päinvastaiseksi ), ja nämä ovat aiheita, joihin kannattaa tutustua, mutta jotta tämä alkuperäinen idea pysyisi mahdollisimman suoraviivaisena, esitän sen tuleva postaus.
Luokan käyttäminen
Yllä olevat vaihtoehdot huomioiden välitämme AcmeColumnin esiintymän HookRegistryyn, kun luokat instantoidaan WordPress-laajennuksen ensimmäisen käynnistysprosessin aikana. Tämä voi näyttää tältä :
<?php
add_action( 'plugins_loaded', 'acme_start' );
/**
* Start the machine.
* https://www.youtube.com/watch?v=ysoMOefPyRs
*/
function acme_start() {
$registry = new HookRegistry();
$acme_column = new AcmeColumn( $registry );
$acme_column->start();
}
Seuraavaksi aina kun on aika pyytää AcmeColumn rekisteröimään toimintonsa WordPressiin, soitamme HookRegistrylle ja opastamme sitä tekemään niin.
Ensinnäkin AcmeColumn :
<?php
class AcmeColumn {
private $registry;
public function __construct( $registry) {
$this->registry = $registry;
}
public function start() {
$registry->add_hook( 'filter', 'manage_edit-page_columns', $this, 'add_page_column' );
}
public function add_page_column( $page_columns) {
$page_columns['template'] = 'Acme Column';
return $page_columns;
}
}
Sitten HookRegistry :
<?php
class HookRegistry {
public add_hook( $type, $name, $object, $method) {
$type = strtolower( $type );
if ('filter' !== $type || 'action' !== $type) {
return new WP_Error( '1', 'No proper hook type defined.' );
}
}
private function add_filter( $name, $object, $method) {
add_filter( $name, array( $object, $method) );
}
private function add_action( $name, $object, $method) {
add_action( $name, array( $object, $method) );
}
}
Valinnaisesti voimme myös ylläpitää luetteloa eri luokista ja koukuista, jotka on rekisteröity. Tämä voi olla hyödyllinen tai ei ehkä hyödyllinen toteutuksestasi riippuen, joten jaan puhtaasti "tässä on jotain, mitä saatat haluta tehdä".
Ja se voisi näyttää tältä (käyttämällä yksinkertaista assosiatiivista taulukkoa):
<?php
class HookRegistry {
private $registry;
public function __construct() {
$this->registery = array();
}
public add_hook( $id, $type, $name, $object, $method) {
$type = strtolower( $type );
if ('filter' !== $type || 'action' !== $type) {
return new WP_Error( '1', 'No proper hook type defined.' );
}
if ('filter' === $type) {
$this->add_filter( $name, $object, $method );
} else {
$this->add_action( $name, $object, $method );
}
$hook_info = array(
$type,
$name,
$object,
$method,
);
$this->registry[ $id ] = $hook_info;
}
private function add_filter( $name, $object, $method) {
add_filter( $name, array( $object, $method) );
}
private function add_action( $name, $object, $method) {
add_action( $name, array( $object, $method) );
}
}
Huomaa, että yllä olevassa luokassa se hyväksyy nyt $id :n parametrina. Voit tunnistaa rekisteriin menevät tiedot useilla tavoilla, joista helpoin on luoda tunnus itse.
Kuitenkin, jos haluat käyttää jotain, kuten koukun tai luokan nimeä, sekin toimisi. Huomaa vain, että koska se on assosiatiivinen matriisi, se voi säilyttää vain yhden arvon avainta kohden, joten voit päätyä roskakoriin aiemman tiedon, jos et ole varovainen.
Tästä huolimatta pidän tätä valinnaisena, mutta jos se on otettu käyttöön, on tärkeää varmistaa, että sinulla on oikeat toiminnot objektin esiintymän hakemiseen avaimella.
Yksi monista
Kuten kaiken tämäntyyppiseen työhön liittyvän, tämänkin on mahdollista suunnitella tai suunnitella uudelleen tavalla, joka toimii eri tavalla tai sopii tarpeisiisi. Tarkoituksena ei ole näyttää lopullista kaavaa, miten jotain tehdään, vaan tapa lähestyä ja mukauttaa sitä (kuten mikä tahansa suunnittelumalli).
Lisäksi sen tarkoituksena on varmistaa, että luokkamme säilyttävät vastuut, joita varten ne on luotu, samalla kun he voivat rekisteröityä WordPressiin tarpeen mukaan. Tällä kertaa luokan ei kuitenkaan tarvitse tehdä sitä itse.
Sen sijaan se siirtää vastuun luokalle, joka on yksin vastuussa mainittujen koukkujen rekisteröimisestä. Joten vaikka se tuo lisää luokkia, se lisää koheesiota ja vähentää kytkentää.
Tämä tarjoaa etuja ylläpidossa, testauksessa ja yleisessä suunnittelussa.