WordPressi vidinad: ümbertöötamine, 3. osa
WordPress Widget Boilerplate’i värskendamisel (mida kõike jälgitakse arendusharus ) oleme selle korralduse ümberkujundamise osas kaugele jõudnud.
Siiani oleme:
- vaatas, kuidas WordPressi vidina API pakub näidet objektorienteeritud programmeerimisest,
- kuidas saame seda API -d kasutada objektorienteeritud programmeerimise määramiseks WordPressi muudes valdkondades,
- installitud tööriistad, mis aitavad meil koodi kvaliteeti hinnata,
- leidnud vead, mis praeguste programmeerimisstandardite kohaselt koodis eksisteerivad ,
- ja alustas koodibaasi ümberkorraldamist, et see sobiks kaasaegsemate tavadega.
Nüüd oleme valmis alustama selle koodi ümberkujundamist palju rohkem objektorienteeritud viisil.
Nii et kui te pole veel eelmiste postitustega (mõnegi neist) järele jõudnud, soovitan seda teha, sest selle ajakohastamiseks kulub veidi aega. Selgitamiseks on palju koodi.
Alustame.
WordPressi vidina katlaplaat: ümberkujundamine, 3. osa
Väidetavalt on Boilerplate’i suurim probleem see, et kõik on kapseldatud ühte klassi.
Muidugi on mõned toredad asjad, nagu meie vaadete eraldamine serveripoolsest loogikast, kuid see on umbes nii kaugele, kui see läheb.
Muud probleemid, mis ilmnevad ainult koodi vaatamisest, on järgmised:
- toimingute ja filtrite lisamine konstruktorisse,
- meetodid, mis teevad rohkem kui ühte asja,
- klasside puudumine, mis vastutavad selliste asjade rakendamise eest nagu sõltuvuste registreerimine,
- ja nii edasi.
Selles postituses alustame abstraktsioonide loomise protsessi, mida lõpuks rakendame, et purustada Boilerplate’i jumalaklassilaadne olemus praegusel kujul.
See jagatakse mitmeks postituseks, et saaksin anda kindla selgituse selle kohta, miks me teatud asju teeme, ja selgitada selle taga olevaid näiteid.
Kui ma teen seda muul viisil, jätab seeria välja liiga palju väärtuslikku teavet, mis on kohaldatav muude objektorienteeritud programmeerimistavade jaoks.
Mis on tellija?
WordPressi konksusüsteem – see tähendab meil saadaolevad toimingud ja filtrid – põhineb sündmustepõhisel disainimustril. See tähendab, et kui midagi juhtub, sündmus, käivitab WordPress mis tahes muu koodi, mis on selle sündmuse tellinud.
Nii et kui registreerime funktsiooni konksuga, siis liitume sündmusega. Sel eesmärgil olen fänn, kes loob tellijaid igale konkreetsele konksule, mida me vajame.
Lisaks järgivad abonendid üldiselt ühtset vormingut. See tähendab, et on väga lihtne luua abstraktset klassi, mis rakendab mõnda ühtset funktsionaalsust ja võimaldab seejärel abstraktset klassi rakendaval klassil keskenduda ainult äriloogikale.
Üks lihtsamaid viise selle demonstreerimiseks on CSS-failide ja JavaScript-failide tellija, kuna need on kaks kõige levinumat asja, mida me pistikprogrammide loomisel kasutame.
Abstraktse klassi loomine
Enne abstraktse klassi rakendamist kirjeldame täpselt, mida me selle loomiseks tegema hakkame.
- Vajame atribuuti, mis esindab sündmust, mida me tellime.
- Vajame funktsiooni, mis käivitaks alati, kui WordPress konksu välja laseb. Teine mõtteviis on see, et vajame funktsiooni, mida rakendada alati, kui WordPress käivitab teatud toimingu või filtri.
- Abstraktsiooni rakendamiseks vajame klasse.
Esiteks määratleme abstraktsed klassid. Otse PHP käsiraamatust loeme:
Abstraktsetena määratletud klasse ei tohi instantseerida ja iga klass, mis sisaldab vähemalt ühte abstraktset meetodit, peab samuti olema abstraktne. Abstraktsetena määratletud meetodid deklareerivad lihtsalt meetodi allkirja – nad ei saa defineerida rakendamist.
Lühidalt tähendab see, et me ei saa tegelikult luua abstraktse klassi eksemplari. Me saame luua ainult klassid, mis määratlevad teostuse.
See aga ei tähenda, et abstraktne klass ei saaks rakendada konkreetseid asju (näiteks konksu määratlus). Kuid see tähendab, et on teatud meetodeid, mida ei rakendata.
Muidu jääb meile lihtsalt põhiklass.
On loogiline? Heidame pilgu peale.
Abstraktse klassi loomine
Selle postituse jaoks loome abstraktse klassi spetsiaalselt CSS-failide ja JavaScripti jaoks.
Pidage meeles, et kuna see on abstraktne klass, võib konkreetseid tellijaid nimetada millekski, mis tuvastab, mida nad teevad (st nad võivad nimetada end kõigeks, mis esindab nende eesmärki). Ja me jõuame selleni.
Aga kõigepealt abstraktne klass. Jagan koodi ja selgitan täpselt, mis sellega toimub:
<?php
/*
* This file is part of the WordPress Widget Boilerplate
*
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateSubscriber;
/**
* An abstract implementation of a subscriber that requires a hook and the ability to
* start the class.
*/
abstract class AbstractSubscriber
{
/**
* @var string a reference to the hook to which the subscriber should be registered
*/
protected $hook;
/**
* @param string $hook the hook to which the subscriber is registered
*/
public function __construct(string $hook)
{
$this->hook = $hook;
}
/**
* @return string the hook to which the subscriber is registered
*/
public function getHook(): string
{
return $this->hook;
}
/**
* Implements the domain logic for the concrete class implementating this subcriber.
*/
abstract public function load();
}
- Pange tähele, et meie loodud vara on kaitstud. Seda selleks, et rakendusklassid pääseksid sellele juurde, kuid miski väljaspool seda ei saa.
- Olen loonud funktsiooni konksu kättesaamiseks, mis selgub hiljem. Tavaliselt ma vihkan selliste funktsioonide rakendamist, mis pole kohe ilmsed, kuid see on oluline, võttes arvesse, kuhu me teel oleme.
- On olemas abstraktne funktsioon, mida nimetatakse koormuseks. See on koht, kus iga klass, mis seda funktsiooni rakendab, sisaldab oma äriloogikat, nagu näeme kohe.
- Mulle meeldib vajadusel dokumenteerida funktsioonide otstarve, et need oleksid ühes kohas ja seejärel lasen rakendusklassidel esitada dokumentatsiooni, mida nad peavad oma juurutamisel esitama. Näete seda ka kohe.
Nüüd, kui abstraktne klass on paigas, on viimane asi, mida peame tegema, et veenduda, et see on paigutatud õigesse kataloogi ja nimeruumi. Kui olete eelmise postitusega alustanud, olete tõenäoliselt suutnud koodis oleva nimeruumi põhjal arvata, kus see asub.
Ja kui ei, siis ärge muretsege. Nimeruumide ja muu väljamõtlemine võib võtta veidi aega. Nii et nende liikmepostituste ja näidete kaudu loodan, et see saab aja jooksul selgeks.
Betooniklasside loomine
Nüüd rakendame seda konkreetset klassi, et lisada nii meil olevad stiilitabelid kui ka JavaScripti allikad. Mida te märkate, on see, et need on väga sarnased.
Ainus asi, mis erineb, on laadimisfunktsiooni rakendamine, mis täpselt peaks toimima.
Stiilitabelid
Arvestades ülaltoodud abstraktset klassi, peame nüüd looma stiilitabelite registreerimiseks klassi. Kuna meil on kaks laaditabelit, loome kaks klassi:
- esimene klass vastutab laaditabeli registreerimise eest armatuurlauale ja konkreetselt WordPressi vidina lehele,
- teine klass vastutab plugina registreerimise eest tegeliku ajaveebi jaoks.
Nimetagem neid kõiki vastavalt AdminStylesheetSubscriberiks ja PublicStylesheetSubscriberiks.
Esiteks administraatori laaditabeli tellija :
<?php
/*
* This file is part of the WordPress Widget Boilerplate
*
* (c) Tom McFarlin <tom@tommcfarlin.com?
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateSubscriber;
/**
* The subscriber responsible for loading the stylesheet on the Widget administration page.
*/
class AdminStyleAssetSubscriber extends AbstractSubscriber
{
/**
* {@inheritdoc}
*/
public function __construct(string $hook)
{
parent::__construct($hook);
}
/**
* Adds the administrative stylesheet to the widget administration page.
*/
public function load()
{
if ('widgets' !== get_current_screen()->id) {
return;
}
wp_enqueue_style(
'wordpress-widget-boilerplate',
plugin_dir_url(dirname(__DIR__)).'assets/css/admin.css'
);
}
}
Pange tähele, et see kasutab funktsiooni get_current_screen(), mida olen kasutanud eelmistes postitustes, veendumaks, et lisame sõltuvusi ainult vajaduse korral.
Nüüd avalik JavaScripti tellija. See kasutab funktsiooni is_admin() veendumaks, et me pole WordPressi haldusalas.
<?php
/*
* This file is part of the WordPress Widget Boilerplate
*
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateSubscriber;
/**
* The subscriber responsible for loading the stylesheet on the blog.
*/
class PublicStyleAssetSubscriber extends AbstractSubscriber
{
/**
* {@inheritdoc}
*/
public function __construct(string $hook)
{
parent::__construct($hook);
}
/**
* Adds the stylesheet to the public-facing side of the site.
*/
public function load()
{
if (is_admin()) {
return;
}
wp_enqueue_style(
'wordpress-widget-boilerplate',
plugin_dir_url(dirname(__DIR__)).'assets/css/widget.css'
);
}
}
Ilmselgelt ei ole me neid klasse veel tegelikkuses loonud. See tuleb sarjas hiljem.
JavaScript
JavaScripti tellijad ei ole palju erinevad, nagu võite arvata. Eraldame need vastavalt rakenduse alale, millele nad keskenduvad, ja anname neile sobiva nime.
Esiteks administraator JavaScripti tellija :
<?php
/*
* This file is part of the WordPress Widget Boilerplate
*
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateSubscriber;
/**
* The subscriber responsible for loading the JavaScript on the Widget's adminsitration page.
*/
class AdminScriptAssetSubscriber extends AbstractSubscriber
{
/**
* {@inheritdoc}
*/
public function __construct(string $hook)
{
parent::__construct($hook);
}
/**
* Adds the administrative JavaScript to the widget administration page.
*/
public function load()
{
if ('widgets' !== get_current_screen()->id) {
return;
}
wp_enqueue_script(
'wordpress-widget-boilerplate',
plugin_dir_url(dirname(__DIR__)).'assets/js/admin.js'
);
}
}
Ja avalik JavaScripti tellija:
<?php
/*
* This file is part of the WordPress Widget Boilerplate
*
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateSubscriber;
/**
* The subscriber responsible for loading the JavaScript on the blog.
*/
class PublicScriptAssetSubscriber extends AbstractSubscriber
{
/**
* {@inheritdoc}
*/
public function __construct(string $hook)
{
parent::__construct($hook);
}
/**
* Adds the JavaScript to the public-facing side of the site.
*/
public function load()
{
if (is_admin()) {
return;
}
wp_enqueue_script(
'wordpress-widget-boilerplate',
plugin_dir_url(dirname(__DIR__)).'assets/js/widget.js'
);
}
}
Jällegi, neid klasse ei saa veel instantseerida, kuid keskendume sellele tulevases postituses.
Abstraktsioonid ja liidesed
Pidage meeles, et abstraktsioonid ja liidesed on erinevad, kuid neid on lihtne segi ajada. Liidesed ei sisalda absoluutselt nulli rakendamist. Selle asemel annavad need garantii, et iga liidest rakendav klass rakendab kõiki meetodeid.
Abstraktsetel klassidel võib seevastu olla abstraktses klassis rakendatud mõningaid funktsioone, jättes samal ajal domeenispetsiifilise koodi (nt laaditabelite ja JavaScripti laadimine) sobivale meetodile.
See selgub, kui seda veel pole, siis mida kaugemale me sellesse sarja jõuame. Seni – ja nagu ikka – ärge unustage tutvuda arendusharuga, et näha, kus me koodiga seisame.