Nimitilat ja automaattinen lataus WordPressissä

Viime viikolla pidin esitykseni WordCamp Atlantassa nimitiloista ja automaattisesta latauksesta. (koko nimi oli Namespaces, Autoloading ja Improving Plugin Architecture, mutta se on suupala, eikö?)

Puheen luonteesta johtuen olen päättänyt kirjoittaa postauksen liitteenä, jakaa dioja ja jakaa esimerkkilaajennuksen GitHubin keskustelun tukemiseksi.

Joten jos olit paikalla, kiitos(!) ja tässä postaus, lupasin. Ja niille teistä, jotka eivät osallistuneet, toivon, että tämä viesti auttaa edelleen havainnollistamaan käsitteitä ja aiheita , joista keskustelin WordCampissa.

Nimiavaruudet ja automaattinen lataus

Ennen kuin puhun nimitiloista ja automaattisesta latauksesta WordPressissä, syy, miksi haluan puhua tästä, on se, että se voi vaikuttaa suoraan koodisi laatuun, ja se voi vaikuttaa niin kuukausien ja vuosien ajan.

Eivätkö monet meistä kehittäjistä esitä jo kysymystä:

Kuinka voimme tehdä koodistamme paremman kuin se jo on?

Ja monet meistä ovat tarpeeksi älykkäitä tietääkseen, mitä emme tiedä. Joten joudumme työskentelemään meille annettujen rajoitusten puitteissa.

Joskus meillä on aikaa tutkia tapoja tehdä tämä; toisinaan teemme työtä sillä tiedolla, joka meillä on. Eikä siinä ole mitään vikaa.

Mutta koska tiedämme, mitä emme tiedä, tiedämme, että potentiaalia on enemmän.

Ensinnäkin koodisi

Kun puhutaan aiheista, kuten nimiavaruuksista ja automaattisesta lataamisesta WordPressin kontekstissa, uskon, että saamme usein ristiriitaisia ​​vastauksia.

Loppujen lopuksi voimme puhua sellaisista asioista kuin Theme Customizer tai REST API tai jostain hauskempaa.

Tarkoitan, "nimitilat ja automaattinen lataus" ei vain kuulosta jännittävältä tai eteenpäin vievältä, kun sitä verrataan saatavilla oleviin uudempiin ominaisuuksiin ja teknologioihin, eikö niin?

Mutta ei, ne eivät todellakaan ole tylsiä. Ja tämän postauksen ja siihen liittyvän esityksen ja lähdekoodin kautta aion näyttää sinulle, miksi ja miten ne eivät ole.

Ne eivät ole tylsiä

Mielestäni on reilua sanoa, että kehittäjät – ainakin osa meistä tai osa heistä riippuen siitä, miltä näet itsesi – ovat pahamaineisia ohjelmoinnin näkökohdista kiistelevänsä.

"Tylsä keskustelu joka tapauksessa."

Itse asiassa ei ole ollenkaan harvinaista kuulla jonkun väittelevän parhaasta tavasta alustaa ja kirjoittaa for-silmukka, joka on mahdollisimman tehokas, kun iteroidaan pienessä tietokantajoukossa huolimatta siitä, että meillä on neliytiminen prosessori ja 16 Gt RAM-muistia. pöytäkoneissamme.

Joten jos välitämme niin paljon jostain niin pienestä, välitämme varmasti isommasta kuvasta. Asiat kuten:

• Paranneltu koodi
• Parempi organisaatio
• Lisääntynyt huollettavuus
• Helpompi virheenkorjaus
• Tienaa enemmän rahaa (ehkä).

Ja nimiavaruudet ja automaattinen lataus voivat johtaa suoraan kaikkeen yllä olevaan (no, en voi puhua rahasta, mutta siinä on potentiaalia).

Jos tekisin yhteenvedon roolien nimiavaruuksista ja automaattisen latauspaikan kaikista yllä olevista, sanoisin seuraavaa:

Nimiavaruudet ja automaattinen lataus johtavat parempaan koodiin paremman organisoinnin, lokeroinnin tai modularisoinnin kautta ja tiiviimpiin suhteisiin konseptien avulla.

Lisäksi tämä lisää ylläpidettävyyttä, koska koodi on järjestetty paketteihin, mikä voi helpottaa virheenkorjausta tuotteen kasvaessa.

Kaikki tämä voi säästää aikaa tai parantaa ajankäyttöä, mikä voi liiketoimintamallistasi riippuen vaikuttaa tulokseen.

Mutta tämä ei silti kuvaa kumpaakaan näistä asioista. Mutta varmasti, tässä vaiheessa ne kuulostavat mielenkiintoisemmilta kuin silloin, kun ne esiteltiin ensimmäisen kerran.

Joten, mitä he ovat?

Ennen kuin käsittelet kunkin roolin määritelmiä, katsotaanpa, kuinka nimiavaruuksien ja automaattisen latauksen puute WordPressissä on vaikuttanut negatiivisesti kokemukseesi, kun käytät teemoja, laajennuksia, lisäosia tai mitä tahansa muuta sinulla on.

Palataanpa siis hetkeksi ja tarkastellaan jokaista erikseen.

Nimiavaruudet

Kuvittele, että olet perinyt projektin ja olet aloittamassa työskentelyä sen parissa. Oletetaan, että se on WordPress-laajennus.

Asennat sen; aktivoit sen ja saat ainakin yhden seuraavista:

• Ehkä näet se ilkeän järjestysviestin selainikkunan yläosassa, jossa näkyy pinojälki.
• Saatat nähdä viestin, joka puhuu ristiriidoista toisen olemassa olevan paketin kanssa.
• Tai ehkä kun yrität aktivoida laajennuksen, sivu päivittyy, mutta laajennus ei aktivoidu.
• Ehkä olet jopa tehnyt kooditarkastuksen ja näet class_exists-tarkistukset koko koodikannassa.

Mikä tahansa tai kaikki edellä mainitut voivat aiheuttaa ongelmia WordPress-projektien kanssa. Mutta nimitilat voivat todella korjata suuren osan tästä suurimman osan ajasta.

Syynä näihin ongelmiin on se, että koodi, jonka kanssa työskentelet, on osa globaalia nimiavaruutta (verrattuna sen nimiavaruuteen), eikä PHP pidä siitä, että luokilla ja moduuleilla on sama nimi. .

Mutta kun annat nimiavaruuden jotain, annat sille sen alueen itseensä nähden, joka silti pelaa hienosti muiden komponenttien kanssa, vaikka niillä olisi sama luokan nimi.

Autoloaders

Mitä tulee autoloaderiin, ne ovat jollain tapaa hieman vähemmän monimutkaisia. Mieti ensin kirjoittamaasi koodia tai koodia, jonka kanssa työskentelet – erityisesti WordPress-laajennusten yhteydessä – ja mieti sitten, kuinka monta kertaa kirjoitat tai näet seuraavan:

• sisältää
• sisällytä_kerran
• vaatia
• vaadi_kerran

Ja joskus näet ne sen tiedoston yläosassa, joka käynnistää laajennuksen, ja joskus näet ne hajallaan koodikannassa.

Jos ne ovat kaikki yhdessä tiedostossa, se ei ole niin paha, koska ainakin tiedät missä ne ovat. Mutta jos niitä roskaa kaikkialla, sinulla ei ole aavistustakaan, mistä riippuvuus tuodaan järjestelmään.

Automaattinen lataus voi ratkaista kaiken tämän lataamalla riippuvuudet tarvittaessa (ja kiinnostuneille automaattinen lataus on nopeampaa kuin manuaalinen lisääminen).

Nimiavaruudet

Kaiken tämän jälkeen olemme valmiita puhumaan sekä nimiavaruuksista että automaattisesta latauksesta. Mutta nimitilat ovat peruskäsite, joten aloitamme siitä.

Mutta kaiken edellä mainitun jälkeen voit nähdä niiden käytön edut. Ehkä ne ovat jopa hauskoja, eikö? Voi olla?

Siitä huolimatta tarvitsemme määritelmän, jonka pohjalta voimme työskennellä, kun puhumme tästä artikkelin loppuosan ajan.

PHP-käsikirja sisältää seuraavan määritelmän :

Nimiavaruudet on suunniteltu ratkaisemaan kaksi ongelmaa, joita kirjastojen ja sovellusten tekijät kohtaavat luodessaan uudelleenkäytettäviä koodielementtejä, kuten luokkia tai toimintoja…

Ja se ei ole huono, mutta se on melko pitkä, tekninen, ja se saattaa olla vähän paljon niille, jotka ovat vasta aloittamassa. Yksinkertaistetaanpa hieman tätä artikkelia varten:

Ehkä vähän paremmin?

Tapa ryhmitellä toisiinsa liittyviä luokkia ja käyttöliittymiä, joilla on samanlainen tarkoitus.

En aio puhua tässä keskustelussa käyttöliittymistä; Tiedän kuitenkin, että on olemassa keskitason oliokehittäjiä, jotka käyttävät niitä, joten halusin varmistaa, että ainakin mainitsen heidät.

Käytännön esimerkki

En pidä ohjelmointiesimerkeistä, jotka eivät anna todellisia tai käytännön sovelluksia. Usein meille annetaan esimerkkejä asioista, joita emme koskaan kodifioisi.

Kuinka monta kertaa olet lukenut olio-artikkelin ja se antaa esimerkin eläinluokasta tai autoluokasta? Emme aio ohjelmoida autoa.

Työskentelemme paljon todennäköisemmin tiedostojen kanssa. Joten aiomme tarkastella joukkoa luokkia, jotka vastaavat tiedostojen lukemisesta ja kirjoittamisesta. Toisin sanoen olemme olleet hyviä olio-ohjelmoijia ja erotelleet luokkamme heidän ylläpitämiensä vastuiden perusteella.

Ja kyllä, sinulla voi olla rajapintoja; ne eivät kuitenkaan kuulu tämän artikkelin piiriin, joten niitä ei sisällytetä.

Joten FileReaderillemme luokan perusteet näyttävät ehkä tältä:

Luokka tiedostojen lukemiseen.

Huomaa, että funktio hyväksyy sen tiedoston nimen, joka sen pitäisi avata luettavaksi. Virheiden tarkistaminen, kuinka se lukee tiedoston ja mitä se palauttaa, on kaikki jätetty luokan toteutuksen vastuulle.

Ja FileWriterille meillä on jotain tämän kaltaista:

Luokka tiedostojen kirjoittamiseen.

Tämä luokka toisaalta hyväksyy tiedot, jotka se aikoo kirjoittaa levylle ja tiedoston nimen, johon se tulee kirjoittaa.

Jälleen, kuten yllä olevassa esimerkissä, se ei sisällä virheiden tarkistamista, resurssin kautta kirjoittamista, resurssien sulkemista ja niin edelleen.

Mutta tässä ei ole kyse tiedostojen käsittelystä. Sen sijaan kyse on koodin nimiavaruuden osoittamisesta, ja näiden kahden esimerkin on tarkoitus olla perustana sille.

Huomautuksia nimiavaruuksista

Yllä olevan esimerkkikoodin kuvissa näkyy varoitus: Näitä luokkia ei ole nimetty. Toisin sanoen he asuvat globaalissa nimiavaruudessa, mikä jättää heidät kypsiksi konflikteihin muiden luokkien kanssa.

Katso asiaa tältä: Kuvittele, että pakkaat tämän koodin lisäosaan jonkun muun puolesta, ja sitten he lataavat toisen laajennuksen, jolla on myös FileReader tai FileWriter. Koska se kaikki tulee olemaan osa samaa globaalia nimiavaruutta, joudut kohtaamaan konfliktin.

Muistaa:

Nimiavaruudet ovat tapa ryhmitellä toisiinsa liittyviä luokkia ja käyttöliittymiä, joilla on samanlainen tarkoitus.

Otetaan siis luokat ja nimiavaruuteen koodi.

Ensin tarjoamme ylimmän tason nimitilan, jonka alla nämä luokat ja kaikki muut luokat sijaitsevat; sitten tarjoamme alipaketin (tai alinimiavaruuden tai aliavaruuden, kuten olen kuullut niitä kutsuttavan), johon nämä tiedostoluokat sijaitsevat.

Tämä tarkoittaa, että FileReader näyttää nyt tältä:

Nimiavaroitu luokka tiedostojen lukemiseen.

Ja FileWriter-ohjelmamme näyttää nyt tältä:

Nimiavaroitu luokka tiedostojen kirjoittamista varten.

Ensinnäkin voit nähdä, että nimiavaruuksien käyttäminen on helppoa: Käytät vain nimiavaruuden avainsanaa ja ilmoitat sitten nimiavaruuden (joka voi yhtä helposti olla WCATL) yläreunassa alipakettien jälkeen.

Mutta tämä johtaa muihin aiheisiin – nimittäin tiedostojen järjestämiseen, toteutukseen ja automaattiseen lataamiseen – jotka kaikki ovat käsittelyn arvoisia.

Tiedoston järjestämisestä

Tässä vaiheessa on tärkeää saada sanaa tiedostojen järjestämisestä. Riippuen siitä, kenen kanssa puhut, tulet huomaamaan, että joillakin kehittäjillä – yllätys, yllätys – on mielipide siitä, miten tiedostot pitäisi järjestää (enkä minä eroa).

Toisaalta sinun ei tarvitse järjestää tiedostojasi ollenkaan. Itse asiassa voit pudottaa jokaisen asian projektisi juurihakemistoon, nimiavaruuteen tiedot ja olla valmis lähtemään.

Järjestämättömät tiedostot

Yllä oleva tiedostojoukko on tarkoitettu pienelle projektille, joten voit kuvitella kuinka monta tiedostoa on olemassa suuressa projektissa.

Mutta kun olet järjestänyt tiedostosi tällä tavalla, se voi tehdä automaattisen latausohjelman kirjoittamisesta hieman vaikeaa, koska automaattilataajan on tiedettävä, mistä tiedostot löytyvät niiden nimitilan perusteella.

Tässä termit "looginen organisaatio" ja "virtuaalinen organisaatio" tulevat esiin.

• Looginen organisaatio viittaa siihen, kuinka tiedostot on järjestetty levylle, kuten yllä näet. Ne sijaitsevat loogisesti juurihakemistossa.
• Virtuaalinen organisaatio viittaa siihen, kuinka tiedostot on järjestetty nimiavaruuksiensa suhteen. Tämä tarkoittaa, että on hakemistoja ja alihakemistoja, jotka yhdistetään nimiavaruuksiin, alipaketteihin ja niin edelleen.

Jos siis ottaisit yllä olevan projektin, sen nimitilat, sen alipaketit ja järjestäisit ne sitten sekä loogisesti että virtuaalisesti, se näyttäisi suunnilleen tältä:

Nimiavaruudet ja automaattinen lataus: Järjestetyt tiedostot

Ja vaikka voit järjestää tiedostosi haluamallasi tavalla, pidän siitä, että näiden kahden välillä on pariteetti. Toisin sanoen pidän siitä, että looginen ja virtuaalinen organisaationi vastaavat toisiaan, kuten näet yllä olevassa kuvassa.

Kun siirryn keskustelemaan automaattisesta latauksesta, näet, miksi tällä on merkitystä.

Huomautuksia nimiavaruuksista

Mitä tapahtuu kuitenkin, kun meidän on instantoitava nimiavaruusluokkia? Kun luokilla ei ole nimiavaruutta, on helppo käyttää "uusi"-avainsanaa.

Instanssi ilman nimiavaruutta.

Mutta meidän on luotava nimiavaruusluokka, meidän on otettava se askel pidemmälle ja käytettävä täysin pätevää nimeä:

Nimiavaruudet ja automaattinen lataus: Instantiation nimiavaruudella.

Mutta tästä tulee hankalaa, eikö? Tämä esimerkki ei ole niin huono, mutta kuvittele, jos työstäisit jotain, jossa on enemmän alipaketteja. Siitä tulisi aika hankalaa, eikö?

Tätä varten voimme käyttää niin kutsuttua aliasausta. Se on myös yksinkertainen. Voimme määrittää käyttämään tiedoston yläosassa olevaa "use"-avainsanaa viittaamaan nimiavaruuteen, jolle haluamme aliaksen, ja sitten käyttää viimeistä alipakettia osana aliasta luokkamme ilmentämiseen.

Kuulostaa hämmentävältä, eikö? Ehkä sen näkeminen toiminnassa auttaa:

Nimiavaruuksien aliasointi.

Ja siinä kaikki. Kyllä, voit viedä aliaksen vielä pidemmälle, mutta tämä on sikäli kuin otan sen tämän artikkelin yhteydessä.

Automaattinen lataus

Tässä vaiheessa meillä on luotu perusta automaattilataukselle. Kyllä, nimitilojen käsittely voi olla paljon työtä, jos et ole tottunut siihen; On kuitenkin tärkeää ymmärtää, koska automaattinen lataus vaatii hieman työtä, joka voi olla odottamatonta, jos et ole koskaan tutustunut siihen.

Tästä huolimatta tärkeimmät asiat, jotka on muistettava nimiavaruuksista tässä vaiheessa, ovat:

1. Nimiavaruudet ovat tapa ryhmitellä toisiinsa liittyviä luokkia ja käyttöliittymiä, joilla on samanlainen tarkoitus.
2. Luo pariteetti tiedostojesi ja nimiavaruuksien kautta varmistaen, että looginen ja virtuaalinen organisaatiosi ovat samat.

Ja nyt on aika todella tarkastella automaattista latausta.

Huomautuksia automaattisesta latauksesta

Katsotaanpa ensin PHP-käsikirjan automaattisen latauksen määritelmää :

Funktio spl_autoload_register() rekisteröi minkä tahansa määrän automaattilataajia, mikä mahdollistaa luokat ja liitännät ladataan automaattisesti, jos niitä ei ole määritetty. Rekisteröimällä automaattilataajia PHP:lle annetaan viimeinen mahdollisuus ladata luokka tai käyttöliittymä ennen kuin se epäonnistuu virheen takia.

Se ei ole huono. Se on kuitenkin pitkä. Joten aivan kuten teimme nimiavaruuksien kanssa, käytetään lyhyempää määritelmää tälle artikkelille:

Tapa ladata liitännät ja luokat automaattisesti ilman include- ja demand -lauseita.

Jälleen kerran, emme käytä käyttöliittymiä tässä artikkelissa, vaikka jotkut kehittäjät käyttävätkin. Ja se tarjoaa toimivan määritelmän tämän artikkelin loppuosaa varten.

Käytännön esimerkki

Kun tiedostosi on järjestetty, nimiavaroitunut ja valmiina ladattaviksi, on aika tehdä juuri niin, eikö niin? Tarkoitan:

1. tiedostosi on järjestetty,
2. olet valmis lataamaan ne

Joten on aika tehdä se automaattisesti, eikö? Mutta siinä on saalis. Koko tiedostojen "automaattinen lataus" vaatii hieman työtä.

Autoloaderin kirjoittaminen

Eli se on automaattinen, mutta vaatii silti hieman enemmän työtä meiltä. Ennen kuin siirryt näihin vaiheisiin, on tärkeää huomata:

1. se ei ole täysin automatisoitu,
2. meidän on kirjoitettava se.

Niin mukavaa kuin olisikin, että koodi latautuu automaattisesti, meidän on luettava joitakin tietoja, jäsennettävä ne ja yritettävä sitten ladata oikea tiedosto.

Mutta olettaen, että kirjoitat sen oikein ja nimiavaruutesi ja järjestät tiedostot samalla tavalla jokaisessa projektissa, voit käyttää automaattista latausohjelmaa uudelleen. Eli kirjoitat sen kerran ja voit käyttää sitä muissa projekteissa.

Autoloaderin vaiheet

Kun kirjoitat automaattista latausohjelmaa, sinun on noudatettava vain muutamia vaiheita. Autoloaderin on kyettävä vastaamaan seuraaviin tiedostoihin:

1. Missä tiedostot ovat?
2. Miten ne on nimetty?
3. Onko tiedosto olemassa?

Jos kaikki edellä mainitut ovat totta (tai voit vastata "kyllä" kaikkiin), niin automaattinen latausohjelma tekee sen, mitä sen pitäisi tehdä.

Katsomme koodia hetken kuluttua, mutta ensimmäinen asia, joka on huomioitava, on, että tämä käyttää toimintoa nimeltä spl_autoload_register.

SPL viittaa standardiin PHP-kirjastoon ja funktio hyväksyy funktion argumenttina, ja tämä funktio hyväksyy ilmennettävän luokan nimen. Se on pikemminkin menettelyllinen kuin oliokeskeinen, ja puhun tästä hetken, mutta on tärkeää pitää mielessä, kun luet tätä koodia.

Tässä on koodin ensimmäinen osa. Selitän sen jälkeen mitä se tekee:

Automaattinen lataus, osa 1 – Luokan löytäminen

Tässä koodin osassa funktio vastaanottaa ilmennettävän luokan täydellisen nimen (kuten “WCATLFileFileReader()").

Seuraavaksi se erottaa kaikki täydellisen nimen osat osiin. Luokan nimi on taulukon viimeinen indeksi, ja päätän nimetä tiedostoni nimellä "class-filereader.php", jotta funktio luo muuttujan $class_file, joka viittaa tiedoston nimeen.

Mutta emme ole vielä valmiita. Meidän on silti hankittava täydellinen nimi (eli missä tiedosto sijaitsee levyllä). Tämä saattaa näyttää tältä:

Automaattinen lataus, osa 2 – Täysin pätevän nimen saaminen

Tässä vaiheessa valmistelemme muuttujan $full_qualified_path, joka viittaa ylätason hakemistoon.

Seuraavaksi koodi iteroidaan kaikkien taulukon indeksien läpi ja luo polun luokkatiedostolle. Voit kuvitella tämän muodostavan merkkijonon, kuten "wcatlfile", jonka sitten yhdistämme $class_file-tiedoston kanssa.

Tämä tarkoittaa, että tiedoston täydellisestä polusta tulee "wcatlfileclass-filereader.php".

Ja lopuksi sisällytämme tiedoston. Huomaa, että tämä koodi ei tarkista, onko tiedosto olemassa. Vaikka suosittelenkin sitä, se on jätetty pois pituuden vuoksi ja koska esimerkissämme tiedämme, että tiedosto on olemassa.

Jos tiedostoa ei ole olemassa, on useita vaihtoehtoja:

1. Tee poikkeus,
2. Ota kiinni poikkeus,
3. Näytä oma virheilmoitus,
4. Tai jokin muu vaihtoehto, jota saatan harkita tässä artikkelissa.

Siitä huolimatta, ideana on suojautua koodissasi, jotta voit valmistautua tilanteeseen, jossa tiedostoa ei ole olemassa, ja voit käsitellä virheen sulavasti.

Automaattilatauksessa

Ennen kuin päätät, on tärkeää huomioida seuraava:

• Koko esimerkin ajan olemme käyttäneet oliopohjaista koodia koodin nimivälissä. Loppujen lopuksi se on olio-käsite.
• Autoloaderimme on kirjoitettu prosessikoodilla. Mikä antaa?

Viime kädessä tämä liittyy tavalliseen PHP-kirjastoon. Voit kirjoittaa oliokeskeisen automaattilataimen, mutta mielestäni se on monissa tapauksissa hieman ylivoimaista.

Tiedoston latausprosessi on vaiheittainen prosessi, joten sen kirjoittaminen menettelytapaan sopii luonnollisesti.

Lopuksi muut voivat halutessaan käyttää työkaluja, kuten Composer, tuodakseen riippuvuuksia. Nämä ovat loistavia työkaluja, ja tämän kaltaisten asioiden käyttämisessä on paljon etuja; Se on kuitenkin tämän artikkelin käsitteiden ja aiheiden ulkopuolella, ja se on parasta jättää tulevaa keskustelua varten.

Resurssit (ja kiitos!)

Tämä on ollut yksi pisimmistä sivustolleni kirjoittamistani artikkeleista.

Tämä johtuu osittain siitä, että se perustuu WordCamp-puheen, ja myös siksi, että haluan varmistaa, että tarjoan vankan johdannon ja perustan, jonka avulla voit aloittaa nimitilan sisällyttämisen ja automaattisen lataamisen WordPress-laajennuksiin.

Tämän artikkelin lisäksi olen toimittanut myös seuraavat resurssit:

• Esitykseni diat ovat saatavilla SpeakerDeckissä.
• Minulla on tämän esityksen koodi ladattavissa GitHubista.

Ja sen myötä toivon, että tämä tarjoaa vankan johdannon nimikirjoituksiin ja automaattiseen lataamiseen ja että voit alkaa sisällyttää tätä yhä enemmän työhösi. Siitä on paljon hyötyä työllesi ja muille kehittäjille, jotka saattavat päätyä käyttämään työtäsi.