WordPress-asetusruutujen järjestäminen
Koska monet meistä jatkavat PHP7+ :n käyttöä, voimme jatkossakin hyödyntää monia kielen tarjoamia uusia ominaisuuksia.
Sillä välin on kuitenkin vielä PHP:n ja siihen liittyvien ohjelmistojen ominaisuuksia, joita voimme käyttää kehitystyön tehostamisessa. Vähin niistä (ja mistä olen kirjoittanut ja puhunut vähän) on nimiavaruudet.
Asia on kuitenkin tässä: Haluan, että liitännäisteni tiedostot ja hakemistot on järjestetty siten, että ne on järjestetty vastaamaan niiden noudattamia nimiavaruuskäytäntöjä. Ja tämä voidaan tehdä taksonomioiden, metalaatikoiden, verkkotunnusobjektien, tietokantoihin liittyvien toimintojen ja niin edelleen.
Tässä viestissä haluan kuitenkin puhua tavasta järjestää WordPress-asetusnäyttöjä sekä loogisista – eli niiden tiedostojärjestelmän sijainnista – että virtuaalisista – eli niiden nimiavaruuksista – organisaatiorakenteista.
WordPress-asetusruutujen järjestäminen
Ensimmäinen asia, jonka haluan tehdä, on tämä: Vaikka puhun WordPress-asetusruutujen järjestämisestä, en puhu mitään API:sta. Oletetaan sen sijaan, että tässä viestissä puhun seuraavista:
- mukautettu valikko, johon liittyy valikkosivu,
- valikkosivu, joka esittää asetussivun vaatimukset (kuten nonce-kenttä ja niin edelleen)
- osa, joka sisältää todelliset asetukset (tai useita osia, jos haluat sisällyttää useita asetuksia).
En aio puhua desinfiointi-, serialisointi-, haku-, validointi- ja näyttöprosessista. Tämä on puhtaasti organisatorista.
Prosessin kautta ajattelu
Koska aiomme järjestää tiedostomme hakemistojen kautta, joissa on myös 1:1 nimiavaruuksia, mietitään tarkasti, mitä tarvitsemme. Tapani lähestyn asiaa on tämä:
- Luomme jotain nimenomaan konteksti-WordPress-sovellusta varten. Tämä osoittaa nimiavaruuden.
- Aiomme luoda hallintavalikon, mikä tarkoittaa, että työskentelemme sekä WordPressin hallintoalueella, eli toisessa nimiavaruudessa, että valikkojen kanssa, jotka ovat toinen nimiavaruus.
- Seuraavaksi tarvitsemme tiedostoja WordPressin vakionäytön näyttämiseen, joten tarvitsemme Views-nimitilan,
- Ja sitten tarvitsemme verkkotunnuskohtaisen koodin pudottamaan näkymään, joten tarvitsemme lopulta Partials-hakemiston (ja siten nimitilan).
Joten lopullinen, looginen tietojen järjestäminen näyttäisi suunnilleen tältä:
Ehkä tärkein asia, joka on huomioitava tässä tiedostojen järjestämisessä, on se, että AdminMenu- luokka on perusluokka, josta kaikki tietyt (tai konkreettisemmat) luokat voivat periä.
Tämä tarkoittaa, että AcmeAdminMenu- luokka perii siltä tietyt ominaisuudet ja toiminnot ja sitten toteuttaa logiikkansa tai lisää myös logiikkansa.
Nimivälit jokaisessa tiedostossa
Kun järjestät tiedostosi tällä tavalla, nimiavaruuksista tulee melkein itsestään selvyyksiä, eikö niin? Tässä on kunkin tiedoston nimiavaruus:
- WordPressAdminMenuAdminMenu
- WordPressAdminMenuAcmeAdminMenu
- WordPressAdminMenuViewsSettings
- WordPressAdminMenuViewsSettingsPartials
Huomaa, että koska acme-settings.php on teknisesti vain merkintä hahmonnusvaihtoehtoja varten, sen ei välttämättä tarvitse olla nimiavaruutta, koska se sisältyy sen hahmontavaan näkymään.
Siitä huolimatta, jos pidät asioiden pitämisestä mahdollisimman järjestyksessä, on järkevää sijoittaa vain osa juuri sellaiseen hakemistoon.
Entä koodi?
Jos olet kiinnostunut näkemään tämänkaltaisen koodin, harkitsen pienen laajennuksen kokoamista, joka näyttää, kuinka tämä kaikki sopii yhteen. Loppujen lopuksi tämä on vähän korkeatasoista, eikö? Tarkoitan, ettei toteutusta ole.
Toisaalta, jos tämä auttaa sinua osoittamaan oikean suunnan nykyistä tai tulevaa projektia varten, se voi riittää.