Vuosia sitten loin WordPress Widget Boilerplaten, jonka tavoitteena on olla seuraava:
Järjestetty, ylläpidettävä pohjalevy widgetien rakentamiseen WordPressin parhaiden käytäntöjen avulla.
Sen jälkeen Widgets-sovellusliittymässä (jota tarkastelemme myöhemmin tässä viestissä) ei ole juurikaan muuttunut, mutta se, mitä pidän "parhaina käytäntöinä", on muuttunut. Lisäksi se, missä määrin tämä API on mielestäni vakaa esimerkki johdanto olio-ohjelmointi WordPressissä on korkea.
Se ei johdu siitä, että se käyttää paljon oliopohjaisia periaatteita, ei siksi, että se käyttää nykyaikaisia standardeja (ainakin nykyaikaisen PHP:n osalta), vaan siitä, että se käyttää muutamia asioita, jotka auttavat meitä tunnistamaan muutamia, esimerkiksi signaalit WordPressin olio-ohjelmoinnista.
Ja tätä ei pidä aliarvioida: Jos etsit esimerkkejä olio-ohjelmoinnista WordPressissä, etsi sitä käyttäviä sovellusliittymiä.
Lisäksi, jos etsit tapoja mitata omaa tasosi koodinpalan arvioinnissa (puhumattakaan koodipohjasta) luokkien ja joidenkin OOP:n edistyneempien ominaisuuksien käyttöä varten, miksi et hankkisi jonkinlaista lakmustestillä nähdäksesi kuinka voit?
Ja Widgets API tekee juuri sen.
WordPress-widgetit: Johdanto
Joten pienemmässä sarjassa kuin edellisessä, aion tarkastella Widgets API:a ja tehdä muutamia asioita:
- näyttää sinulle widgetin perusrungon ja miksi se on oliosuuntautunut,
- keskustella siitä, mitä asioita sinun pitäisi pystyä huomaamaan ja miksi,
- päivitä Widget Boilerplate ensin suoraan tälle sivustolle ja siirrä se sitten GitHubiin,
- rakentaa widget API:n avulla, jonka pohjana on työmme.
Ja tässä viestissä aloitamme ensimmäisestä yllä olevasta kohdasta.
Mutta ensin…
Ennen kuin siirryt tähän postaukseen, suosittelen lukemaan seuraavat viestit:
- Kaksi olio-ohjelmoinnin pilaria: Osa 1/2
- Olio-ohjelmoinnin kaksi pilaria: Osa 2/2
- Abstract Classes, Osa 1 – Abstraktiokäyttäytyminen
- Abstraktit luokat, osa 2 – Abstraktit luokat ja käyttöliittymät
Kun olet valmis (tai jos sinusta tuntuu, että sinulla on jo käsitys aiheista), olemme valmiita lähtemään.
[rajoita maksettua ="true"]
Widgets API:n perusteet
Jos luet Widgetien käsikirjasivun, näet paljon sisältöä. Tämä on hyvä asia, mutta se ei ole aina paras tapa, kun yrität tislata sisältöä itsellesi kaltaiselle yleisölle, kun etsit käytännöllisiä, olio-ohjeita.
Joten aion poimia asiaankuuluvat osat API-dokumentaatiosta ja soveltaa niitä sitten myös toimittamiimme koodiin.
Mikä on widget?
Luulen, että useimmat meistä, jotka työskentelevät WordPressin kanssa, tietävät, mikä widget on, mutta on tärkeää määritellä termi, jotta me kaikki työskentelemme saman idean pohjalta. Käsikirjassa lukee:
Widget on PHP-objekti, joka tulostaa jonkin verran HTML-koodia. Samanlaista widgetiä voidaan käyttää useita kertoja samalla sivulla (esim. Tekstiwidget). Widgetit voivat tallentaa tietoja tietokantaan (asetustaulukkoon).
Kun tämä on paikallaan, katsotaanpa mukautetun widgetin koodia, ainakin osa siitä, ja katsotaan, mitä voimme saada selville sen oliosuuntautuneisuudesta.
Widget-luokka
Ennen kuin edes katsomme koodia, tiedämme, että siellä on jonkin verran olio-ohjelmointia, koska dokumentaatio käskee meitä tekemään kolme asiaa:
- Luo widgetin luokka laajentamalla WP_Widget -standardin luokkaa ja joitakin sen toimintoja.
- Rekisteröi widgettisi, jotta se on käytettävissä Widgetit – näytössä.
- Varmista, että teemassasi on vähintään yksi widget-alue, johon voit lisätä widgetejä.
Tässä viestissä aion keskittyä ensimmäiseen kohtaan (tosin lopulta pääsemme siihen, kuinka esittelemme widgetimme teemaan ennen sarjan päättymistä).
Laitetaan siis koodi sellaisena kuin se on esitetty dokumentaatiossa ja puhutaan siitä, mitä voimme oppia siitä:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Ensinnäkin huomaamme, että vaikka määrittelimme luokan (jolle voimme nimetä mitä haluamme, minun tavallani), sen on laajennettava WP_Widget. Tämä tarkoittaa, että WordPress-ytimessä on WP_Widget- luokka. Voit tarkastella lähdekoodin hyvin organisoitua erittelyä tällä sivulla.
Toiseksi avainsana laajenee osoittaa, että käytämme PHP -perintöä, joka on olioohjelmoinnin peruspilari.
Kolmanneksi meidän on toteutettava neljä funktiota, joista kaksi vaatii argumentteja. Toiminnot, jotka meidän on toteutettava, ovat seuraavat:
- __construct(), joka on perusluokan rakentaja. Tässä meidän on varmistettava, että emoluokan rakentaja kutsutaan, jos sellainen on, ja sitten alustetaan kaikki ominaisuudet, joita katsomme tarpeellisiksi widgetillemme. Tarkastellaan tätä myöhemmin sarjassa.
- widget() vastaa käyttäjän antaman widgetin sisällön tulostamisesta hallinta-alueen käyttöliittymällä. Se hyväksyy kaksi parametria – $args ja $instance. $args – parametri on tiedot, jotka renderöidään sivulla, ja $instance on viittaus widgetin esiintymään (koska sivulla voidaan hahmontaa useita widgetejä).
- form() näyttää hallinnollisen käyttöliittymän, jonka kanssa käyttäjä on vuorovaikutuksessa ohjatakseen sivuston käyttöliittymän tulosteita. Se vaatii myös argumentin $instance, jotta annetut tiedot koskevat todellista widgetiä, jonka kanssa käyttäjä työskentelee (verrattuna kaikkiin widgetin esiintymiin).
- update() -funktiota käytetään arvojen tallentamiseen widgetin nykyiseen esiintymään. Se hyväksyy kaksi argumenttia. Ensimmäinen on widgetin uusi ilmentymä käyttäjän antamilla päivitysarvoilla (ajattele aktiivisen tekstiwidgetin arvon päivittämistä) ja toinen argumentti on widgetin vanhan esiintymän tai ehkä edellisen esiintymän tai kenties " tapaus, jolla oli aikaisemmat arvot."
Nämä neljä toimintoa on otettava käyttöön osana widget-sovellusliittymää, osana toimintojen perimistä laajennetusta käyttöliittymästä ja tuottamaan widgetin perustoiminnot.
Tämä ei tarkoita, etteikö lisää voisi lisätä, mutta hyvällä oliopohjaisella tavalla olisi todennäköisesti parasta siirtää tämä käyttäytyminen muihin luokkiin. Mutta tarkastelemme sitä myöhemmin sarjassa, kun luomme omaa widgetiä.
Mitkä ovat tärkeimmät takeawayt?
Varmistaakseni, että ymmärrän selvästi, mitä tästä viestistä ymmärretään, se on seuraava:
- Widgets API on oliosuuntautunut. Se ei ole vain oliosuuntautunut, koska se käyttää luokkaa (vaikka se on varmasti hyvä lähtökohta), vaan myös siksi, että se perii toiminnallisuuden, joka on rakennettu jo olemassa olevaan perusluokkaan.
- Aina kun perimme käyttäytymisen perusluokalta tai yläluokalta, saamme valmiiksi kehitettyjä toimintoja ilmaiseksi. Se on todella hieno asia olio-ohjelmoinnissa, koska sen avulla voimme keskittyä erityisesti ohjelmointilogiikkaan, jota haluamme toteuttaa.
Kuvittele hetkeksi, että haluat kehittää widgetin, mutta joka kerta, kun teet sen, sinun on kirjoitettava kaikki toiminnot koukkuihin WordPressiin, jotta voit tehdä kaikki samat toistuvat lisäykset.
Tässä tulee esiin perinnöllisyys ja olio-ohjelmointi. Toistuva koodi abstrahoidaan perusluokkaan, joten se kirjoitetaan vain kerran ja sitten koodi, johon haluamme keskittyä, jätetään meidän toteutettavaksi.
Kaikki edellä mainitut asiat on ymmärrettävä, kun luetaan tämä WordPressin oliopohjaisen perussovellusliittymän lähdekoodin ensimmäinen passi.
Mitä seuraavaksi?
Tämän sarjan seuraavassa viestissä tarkastelemme Widgets API:n oliolähtöistä luonnetta ja sitä, mitä asioita sinun pitäisi pystyä havaitsemaan välittömästi lukemalla koodi.
Tämä johtuu siitä, että on tärkeää tunnistaa tietyt olioperiaatteet käytännössä, ja tämä on hyvä tapa arvioida, pystytkö siihen vai et. Jos olet, hienoa! Sitten se auttaa edelleen kehittämään lihaksia. Jos ei, ei hätää – se silti auttaa sinua kehittämään lihaksia.
Ja se palvelee sinua hyvin, kun siirrymme yhä enemmän oliolähtöiseen WordPress-kehitykseen käytännön keinoin.
Tarvittava teoria on käsitelty. Joten aloitetaan sen toteuttaminen käytännössä.