Share
I denne serien er vi i ferd med å snakke om hvordan vi kan bygge webapplikasjoner ved hjelp av WordPress. Og selv om dette ikke er en teknisk serie der vi skal se på kode, vi er som dekker emner som rammeverk, stiftelser, designmønstre, arkitekturer og så videre.
Hvis du ikke har lest det første innlegget i serien, anbefaler jeg det; Men i forbindelse med dette innlegget kan vi oppsummere det forrige innlegget som følger:
Kort sagt, programvare kan bygges på rammer, programvare kan forlenge fundament.
Enkelt sagt, vi differensierte mellom rammeverk og stiftelser - to termer som ofte brukes om hverandre i programvare til tross for at de ikke er de samme. WordPress er et grunnlag fordi det er et program til seg selv. Det er ikke et rammeverk.
For det formål, når det gjelder å bygge webapplikasjoner på WordPress, må vi revurdere arkitektur eller vurdere våre konseptuelle modeller for hvordan applikasjoner bygges.
På høyt nivå mulig, er webapplikasjoner vanligvis strukturert med følgende tre komponenter:
Generelt sett er presentasjonslaget det som brukeren ser og hva brukeren samhandler med. Den inneholder alle stilene, klient-side-koden og markeringen som er nødvendig for å sette noe foran brukeren.
Når brukeren klikker på noe, eller siden gjør informasjon hentet fra databasen, samhandler den med Application Layer.
Applikasjonslaget er ansvarlig for å koordinere informasjon fra nettleseren og / eller fra brukerens handling til databasen. Noen ganger består dette av å skrive informasjon til databasen - for eksempel informasjon fra et skjemafelt - for å lese informasjon fra databasen, som å hente en brukers kontoinformasjon.
I likhet med presentasjonslaget består av forskjellige komponenter - for eksempel stiler, JavaScript, markering og så videre - kan applikasjonslaget bestå av en rekke forskjellige komponenter, for eksempel systemer som er nødvendige for å lese og skrive data til databasen, sanitere informasjon , validering av informasjon og håndheving av visse regler som er unike for problemet ved hånden.
Endelig er databaselaget der dataene lagres. Det kan bestå av filsystemet, det kan bestå av en MySQL-database, eller det kan bestå av en tredjepartsløsning som en datastore som er "i skyen" som Amazon S3 eller noe sånt.
Hovedpoenget til å ta vekk fra dette er at i programvare, har vi alltid å gjøre med noen grad av abstraksjon. For eksempel snakker vi om datalageret eller databaselaget, men vi er egentlig ikke spesifikke. Det samme gjelder med applikasjonslag og presentasjonslag.
Åpenbart ser vi ikke ut til å gi svar på disse spørsmålene akkurat nå, men poenget er at alle webapplikasjoner består av liknende komponenter, men detaljene i hver komponent varierer fra prosjekt til prosjekt.
Som et webprogram selv, er WordPress et perfekt eksempel på hvordan ulike teknologier kommer sammen for å danne et webprogram:
Så det er WordPress-arkitekturen, men hva med prosjektene som vi vil bygge på toppen av applikasjonen? Hvordan følger de samme arkitektur?
Vel, husk at WordPress er et fundament - ikke et rammeverk - slik at vi er utsatt for WordPress 'arkitektur som standard. Dette gjør det ikke betyr at vi ikke kan bringe inn våre egne biblioteker, i noen tilfeller, men det påvirker måten våre applikasjoner og prosjekter er bygget på.
Vi snakker mer om bibliotekene, utvidbarheten og litt mer, men først er det viktig å merke seg at i en dag og alder hvor MVC (og MVVM og andre varianter av modell, se, hva) paradigmet er alle raseri, WordPress gjør ikke følg denne konvensjonen.
Det er argumenter for og imot hvorfor det kan være en god ting eller en dårlig ting, men det er ikke meningen med dette innlegget. I stedet er det bare verdt å merke seg at WordPress bruker et hendelse-drevet mønster, i stedet for modell-visning-kontrollpanelet.
Og i den forbindelse er det verdt å forstå hvordan den hendelsesdrevne modellen fungerer slik at du har en klar forståelse av hvordan WordPress-kroker fungerer, og hvordan du kan skifte du tenker fra MVC eller hva annet paradigme du er vant til å bruke, til hvordan WordPress styrer sin informasjon.
Før vi tar et kikk på et eksempel på et hendelsesdrevet program, la vi se på hva det betyr å følge MVC-paradigmet.
Hele MVC-modellen ser slik ut:
Nå kan hendelsesdrevne applikasjoner ha noen av de samme komponentene - det vil si at de kan ha visninger og modeller eller visninger og dataobjekter - men de trenger ikke nødvendigvis en kontroller som koordinerer informasjon fra forenden til bakenden.
I stedet fungerer hendelsesdrevet programmering ut fra premisset om at "noe som skjedde." Dermed navnet til handlinger i WordPress lingo (selvfølgelig har vi også filtre, men jeg vil dekke dem kort).
WordPress gir kroker som bokstavelig talt peker i utførelsen der vi kan introdusere vår egen funksjonalitet slik at WordPress gjenkjenner at "når denne hendelsen skjer, jeg må brann disse funksjonene" hvor disse funksjonene er definert som hva vi har gitt.
Sannheten er at filtre fungerer på samme måte, men deres formål er annerledes. Kort sagt, filtre er handlinger som er ment å manipulere data (for eksempel legge til, prepending, fjerne eller oppdatere innholdet) på noen måte før du vender tilbake til programmets utførelse.
Så hvordan ser dette ut??
Ingenting veldig komplisert, riktig?
Poenget med denne artikkelen er først og fremst å få oss til å tenke når det gjelder hendelsesdrevet programmering og hvordan vi kan koordinere vår innsats for å bygge webapplikasjoner spesifikt på WordPress.
Det vil si at det er viktig for oss å tenke i form av arrangementer eller det faktum at "noe har skjedd" slik at vi vet når vi skal sette inn våre egne handlinger på riktig måte. Vi snakker litt om dette litt mer i detalj i neste artikkel, men hovedpunktet som jeg vil at dere skal ta bort fra denne artikkelen er at bare fordi noe ikke er MVC (eller hva det neste populære paradigmet er ) betyr ikke at det ikke er godt egnet for applikasjonsutvikling.
Hvert mønster og arkitektur gir oss fordeler og ulemper som alle kan bidra til suksessen med å bygge en webapplikasjon.
Neste i serien ser vi nærmere på hvordan kroker spiller en viktig rolle i å bygge webapplikasjoner på WordPress, og så begynner vi å se på noen av fasilitetene som WordPress tilbyr utenom-boksen som gjør det så solid alternativ for visse typer (les: ikke alle typer) av webapplikasjoner.
Accentsconagua