WordPressi seadete ekraanide korraldamine
Kuna paljud meist jätkavad PHP7+ kasutamist, saame jätkuvalt kasutada paljusid uusi funktsioone, mida keel pakub.
Vahepeal on aga PHP-s ja sellega seotud tarkvaras endiselt funktsioone, mida saame kasutada, et aidata oma arendust sujuvamaks muuta. Vähim neist (ja see, millest ma olen natuke kirjutanud ja rääkinud) on nimeruumid.
Asi on aga siin: mulle meeldib, kui minu pistikprogrammi failid ja kataloogid oleksid struktureeritud nii, et need peegeldaksid nende järgitud nimeruumi tavasid. Ja seda saab teha taksonoomiate, metakastide, domeeniobjektide, andmebaasiga seotud funktsioonide ja muu jaoks.
Selles postituses tahan aga rääkida viisist, kuidas korraldada WordPressi seadete ekraane nii loogilisest – st nende failisüsteemi asukohast – kui ka virtuaalsest – st nende nimeruumidest – organisatsioonistruktuuridest.
WordPressi seadete ekraanide korraldamine
Esimene punkt, mida tahan öelda, on järgmine: kuigi ma räägin WordPressi seadete ekraanide korraldamisest, ei räägi ma API-st midagi. Selle asemel eeldage, et selle postituse puhul räägin järgmisest:
- kohandatud menüü, millel on seotud menüüleht,
- menüüleht, mis esitab seadete lehe nõuded (nt väli nonce ja nii edasi)
- osa, mis sisaldab tegelikke sätteid (või mitut osa, kui soovite lisada mitu seadet).
Ma ei räägi desinfitseerimise, serialiseerimise, otsimise, kinnitamise ja kuvamise protsessist. See on puhtalt korralduslik.
Protsessi kaudu mõtlemine
Arvestades, et hakkame oma faile korraldama kataloogide kaudu, mis on ka nimeruumidega 1:1 vastendatud, mõelgem täpselt läbi, mida me vajame. Ma lähenen sellele järgmiselt:
- Loome midagi spetsiaalselt WordPressi kontekstirakenduse jaoks. See tähistab nimeruumi.
- Loome haldusmenüü, mis tähendab, et töötame nii WordPressi haldusalas, seega teises nimeruumis, kui ka menüüdega, mis on teine nimeruum.
- Järgmiseks vajame faile WordPressi standardekraani kuvamiseks, nii et vajame Viewsi nimeruumi,
- Ja siis vajame vaatesse kuvamiseks domeenispetsiifilist koodi, nii et lõpuks vajame Partialsi kataloogi (ja seega ka nimeruumi).
Seega näeks andmete lõplik, loogiline korraldus välja umbes selline:
Võib-olla on kõige olulisem selle failikorralduse puhul märkida, et AdminMenu klass on põhiklass, millest kõik konkreetsed (või konkreetsemad) klassid võivad pärida.
See tähendab, et klass AcmeAdminMenu pärib sellelt teatud atribuudid ja funktsioonid ning seejärel rakendab oma loogika või lisab selle loogika.
Iga faili nimevahe
Kui te oma faile sel viisil korraldate, muutuvad nimeruumid peaaegu iseenesestmõistetavaks, kas pole? Siin on iga faili nimeruum:
- WordPressAdminMenuAdminMenu
- WordPressAdminMenuAcmeAdminMenu
- WordPressAdminMenuViewsSettings
- WordPressAdminMenuViewsSettingsPartials
Pange tähele, et kuna acme-settings.php on tehniliselt lihtsalt renderdusvalikute märgistus, ei pea see tingimata olema nimeruumiga, kuna see sisaldub seda renderdavas vaates .
Sellest hoolimata, kui armastate asju võimalikult organiseeritult hoida, on mõttekas pesastada ainult osa selle nimega kataloogi.
Aga koodiga?
Kui olete huvitatud millegi sellise koodi nägemisest, kaalun väikese pistikprogrammi kokkupanemist, mis näitaks, kuidas see kõik kokku sobib. Lõppude lõpuks on see natuke kõrgel tasemel, kas pole? Ma mõtlen, et rakendamist pole.
Jällegi, kui see aitab teid praeguse või tulevase projekti jaoks õiges suunas suunata, võib sellest piisata.