Aastaid tagasi lõin WordPress Widget Boilerplate’i, mille eesmärk on olla järgmine:
Korrastatud, hooldatav platvorm vidinate loomiseks, kasutades WordPressi parimaid tavasid.
Sellest ajast peale pole vidinate API -ga seoses palju muutunud (mida me selles postituses hiljem vaatleme), kuid muutunud on see, mida pean "parimateks tavadeks". Lisaks on minu arvates see API kindel määr Sissejuhatava objektorienteeritud programmeerimise näide WordPressis on kõrge.
Asi pole selles, et see kasutab palju objektorienteeritud põhimõtteid, mitte sellepärast, et see kasutab kaasaegseid standardeid (vähemalt tänapäevase PHP osas), vaid sellepärast, et see kasutab mõnda asja, mis aitavad meil mõnda neist ära tunda, näiteks signaalid objektorienteeritud programmeerimise kohta WordPressis.
Ja seda ei tohiks alahinnata: kui otsite WordPressis objektorienteeritud programmeerimise näiteid, otsige API-sid, mis seda kasutavad.
Lisaks, kui otsite viise, kuidas hinnata oma koodijupi (rääkimata koodibaasist) taset klasside ja mõnede OOP-i täiustatud funktsioonide kasutamiseks, siis miks mitte kasutada mõnda koodi lakmuspaber, et näha, kuidas sul läheb?
Ja vidinate API teeb just seda.
WordPressi vidinad: sissejuhatus
Nii et väiksemas seerias kui mu viimane, püüan vaadata vidinate API-t ja teha mõned asjad:
- näidata teile vidina põhilist luustikku ja seda, miks see on objektorienteeritud,
- arutlege, mida peaksite märkama ja miks,
- värskendage esmalt Widget Boilerplate’i otse sellel saidil ja seejärel lükake see GitHubisse,
- looge vidin, kasutades API-d ja katlaplaati meie töö aluseks.
Ja selles postituses alustame ülaltoodud esimese punktiga.
Aga esmalt…
Enne selle postituse juurde asumist soovitan lugeda järgmisi postitusi:
- Objektorienteeritud programmeerimise kaks sammast: 1. osa 2-st
- Objektorienteeritud programmeerimise kaks sammast: 2. osa 2-st
- Abstraktsed klassid, 1. osa – Abstraktne käitumine
- Abstraktsed klassid, 2. osa – Abstraktsed klassid ja liidesed
Kui see on tehtud (või kui tunnete, et olete teemadest juba aru saanud), oleme valmis alustama.
[piira makstud="true"]
Vidinate API põhitõed
Kui loete vidinate käsiraamatu lehte, näete palju sisu. See on hea asi, kuid see ei ole alati parim samm, kui proovite sisu destilleerida sellisele vaatajaskonnale nagu ise, kui otsite praktilisi objektorienteeritud nõuandeid.
Seega valin ma API dokumentatsioonist välja asjakohased osad ja rakendan selle siis meie pakutavale koodile.
Mis on vidin?
Ma arvan, et enamik meist, kes töötavad WordPressiga, teavad, mis on vidin, kuid oluline on see termin määratleda, et me kõik töötaksime sama idee alusel. Käsiraamatus on kirjas:
Vidin on PHP-objekt, mis väljastab HTML-i. Sama tüüpi vidinat saab samal lehel mitu korda kasutada (nt tekstividin). Vidinad suudavad salvestada andmeid andmebaasi (valikute tabelisse).
Kui see on paigas, vaatame kohandatud vidina koodi, vähemalt osa sellest, ja vaatame, mida saame selle objektorienteeritud olemuse osas välja tuua.
Vidinaklass
Enne koodi vaatamist teame, et teatud tasemel objektorienteeritud programmeerimine toimub lihtsalt seetõttu, et dokumentatsioon käsib meil teha kolme asja:
- Looge oma vidina klass, laiendades standardset WP_Widget klassi ja mõningaid selle funktsioone.
- Registreerige oma vidin, et see oleks vidinate ekraanil saadaval.
- Veenduge, et teie teemal oleks vähemalt üks vidinaala, kuhu vidinaid lisada.
Selles postituses keskendun ma esimesele punktile (kuigi lõpuks jõuame selleni, kuidas me oma vidinaid teemasse tutvustame enne sarja lõppu).
Paigutagem kood välja nii, nagu see on dokumentatsioonis, ja räägime sellest, mida saame sellest õppida:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Esiteks märkame, et kuigi me määratlesime klassi (millele saame anda nime, mida iganes tahame), peab see laiendama WP_Widget. See tähendab, et WordPressi tuumas on klass WP_Widget. Sellel lehel saate vaadata lähtekoodi hästi organiseeritud jaotust .
Teiseks näitab märksõna laiendus, et kasutame PHP-i pärimist, mis on objektorienteeritud programmeerimise põhisammas.
Kolmandaks peame rakendama nelja funktsiooni, millest kaks nõuavad argumente. Funktsioonid, mida peame rakendama, on järgmised:
- __construct(), mis on põhiklassi konstruktor. Siin peame veenduma, et kutsutakse välja emaklassi konstruktor, kui see on olemas, ja seejärel initsialiseerime kõik atribuudid, mida me oma vidina jaoks vajalikuks peame. Vaatame seda hiljem sarjas.
- widget() vastutab selle vidina sisu väljastamise eest, mille kasutaja haldusala liidest kasutades pakub. See aktsepteerib kahte parameetrit – $args ja $instance. Parameeter $args on lehel lehel renderdatav teave ja $instance on viide vidina eksemplarile (kuna lehel saab renderdada mitu vidinat).
- form() kuvab haldusliidese, millega kasutaja suhtleb, et juhtida saidi esiotsa väljundit. See nõuab ka argumenti $instance, et pakutav teave oleks tegeliku vidina kohta, millega kasutaja töötab (võrreldes kõigi vidina eksemplaridega).
- update() kasutatakse väärtuste salvestamiseks vidina praegusesse eksemplari. See aktsepteerib kahte argumenti. Esimene on vidina uus eksemplar koos kasutaja antud värskendusväärtustega (mõelge aktiivse tekstividina väärtuse värskendamisele) ja teine argument on vidina vana eksemplari või võib-olla eelmise eksemplari või võib-olla " eksemplar, millel olid eelmised väärtused.
Need neli funktsiooni on vaja rakendada osana vidina API-st, osana funktsioonide pärimisest laiendatud liidesest ja luua vidina põhifunktsioonid.
See ei tähenda, et rohkem ei saaks lisada, kuid hea objektorienteeritud viisil oleks tõenäoliselt kõige parem see käitumine teistesse klassidesse viia. Kuid me vaatame seda hiljem sarjas, kui loome oma vidina.
Mis on peamised pakkumised?
Veendumaks, et saan aru, mida sellest postitusest aru saab, on see järgmine:
- Vidinate API on objektorienteeritud. See pole mitte ainult objektorienteeritud, kuna see kasutab klassi (kuigi see on kindlasti hea lähtepunkt), vaid ka seetõttu, et see pärib funktsionaalsuse, mis on ehitatud juba olemasolevasse baasklassi.
- Kui pärime käitumise põhiklassilt või ülemklassilt, saame tasuta eelarendatud funktsioonid. See on objektorienteeritud programmeerimise puhul tõesti suurepärane asi, sest see võimaldab meil keskenduda konkreetselt programmeerimisloogikale, mida soovime rakendada.
Kujutage hetkeks ette, et soovite arendada vidinat, kuid iga kord, kui seda teete, peate kirjutama kõik funktsioonid konksudesse WordPressi, et kasutada kõiki samu korduvaid katlaplaadi funktsioone.
Siin tulevad mängu pärimine ja objektorienteeritud programmeerimine. Korduv kood lahutatakse baasklassiks, nii et see kirjutatakse ainult üks kord ja seejärel jäetakse kood, millele tahame keskenduda, meie enda teha.
Kõik ülaltoodud on see, mida tuleks mõista, kui lugeda seda algset pääsu WordPressi põhilise objektorienteeritud API lähtekoodist.
Mis järgmiseks?
Selle seeria järgmises postituses vaatleme vidinate API objektorienteeritud olemust ja seda, milliseid asju peaksite koodi lugedes kohe tuvastama.
Selle põhjuseks on asjaolu, et teatud objektorienteeritud põhimõtteid on praktikas oluline ära tunda ja see on hea viis hinnata, kas saate seda teha või mitte. Kui olete, siis suurepärane! Siis aitab see jätkuvalt seda lihast arendada. Kui ei, siis ärge muretsege – see aitab teil ikkagi seda lihast arendada.
Ja see teenib teid hästi, kui me jätkame praktiliste vahenditega üha enam objektorienteeritud WordPressi arendamist.
Vajalik teooria on läbi käidud. Nii et alustame selle tegelikku rakendamist.