Share
Med folk som begynner å realisere WordPress 'potensial som et søknadsstiftelse i stedet for bare et innholdssystem eller en blogging-plattform, fokuserer denne serien på hvordan WordPress kan brukes til slike prosjekter.
En av de viktigste tingene å merke seg er at WordPress ikke er ment å være den endelige løsningen for å bygge webapplikasjoner. Faktisk tror jeg ikke noen grunnlag eller rammeverk er ment å være de endelig løsning.
I stedet har vi en rekke forskjellige valg, som alle gir seg til bedre situasjoner enn andre, og WordPress er ikke annerledes. Gjennom hele denne serien skal vi fortsette å se på hvordan webapplikasjoner kan bygges med WordPress, og hvilke situasjoner som egner seg best for fundamentet. Vi må imidlertid fortsette vår diskusjon om hvordan WordPress fungerer slik at vi kan begynne å snakke om hvordan man bygger applikasjoner på toppen av det.
I den forrige artikkelen diskuterte vi hvor mange rammer som tilbyr en MVC-tilnærming til utvikling, men vi så også på WordPress 'eventdrevne modell. I dette innlegget skal vi se nærmere på det eventdrevne paradigmet som WordPress sysselsetter, og hvorfor dette betyr noe.
Sannheten er at mange mennesker er kjent med dette paradigmet, de er bare ikke kjent med navngivningskonvensjonene. Ved slutten av denne artikkelen bør vi ha en klar forståelse av hva hendelsesdrevet programmering er, hvordan det fungerer, hvordan det implementeres i WordPress, og hvordan vi trenger å tenke på dette når det kommer fra andre mønstre som modellvisning -styring.
I det siste innlegget oppsummerte vi hendelsesdrevet programmering med følgende ide:
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).
Og det er greit for en arbeidsdefinisjon av hendelser, spesielt på et høyt nivå. Men hvis du vil ha en mer grundig titt på hvordan dette ser ut fra et praktisk standpunkt, det vil si fra hvordan WordPress implementerer det - så er det nok det beste du kan gjøre å forstå arrangementer.
Men enda mer enn det, er det viktig å forstå WordPress-sidenes livssyklus, hvor hendelser skjer, og hvordan vi - som utviklere - kan hekte seg til dem for å utføre en bestemt oppgave.
Som vi allerede har nevnt, i hendelsesdrevet programmering, er ideen om hendelser rett og slett det noe har skjedd. Vi fortsetter å repetere det, men hva betyr det egentlig?
I sammenheng med en enkelt sidebelastning er det en rekke ting som oppstår:
Alle disse kan betraktes som hendelser, men hver av disse består av sitt eget sett med mindre hendelser - det vil si, du kan få egentlig detaljert når det skjer noe.
Ta for eksempel ideen om å gjengi en typisk, offentlig-vendt forespørsel om en WordPress-drevet side. Hvis du ser på det tilknyttede Codex-dokumentet, merker du at det er omtrent 50 handlinger som oppstår, og dette gjøres ikke Inkluder også post- eller side-spesifikke handlinger.
Hver av disse handlingene kan betraktes som en hendelse, og i hendelsesdrevet programmering er hendelser vanligvis eksponert på en slik måte at de tillater oss å hekte inn i dem og manipulere informasjon før det blir gjort til klienten.
Derav navnet på kroker.
Selvfølgelig, i WordPress, kommer kroker i to varianter: Handlinger og Filtre. Selv om denne serien ikke handler om en solid opplæring på hver av disse, er den er viktig å gjenkjenne forskjellen i dem som de forholder seg til å arbeide med WordPress.
Handlinger er en type krok som betyr at noe har skjedd, og når at noe skjer, har vi muligheten til å registrere vår egen funksjonalitet slik at vi kan injisere vår egen kode (eller til og med forhindre at visse ting skjer).
Som jeg oppsummerte i min serie om handlinger og filtre:
Handlinger er hendelser i WordPress-sidens livssyklus når visse ting har oppstått - visse ressurser er lastet, enkelte fasiliteter er tilgjengelige, og avhengig av hvor tidlig handlingen har skjedd, har noen ting ennå ikke lastet inn.
Det er viktig å forstå de tilgjengelige handlingene, slik at du vet når den beste tiden å koble seg til en bestemt hendelse, er slik at du ikke hindrer ytelsen til siden, potensielt mangler andre data som kommer nedstrøms, eller slik at du er riktig håndterer informasjonen på riktig tidspunkt og sted.
Filtre, derimot, en type krok som tillater oss å motta et bestemt stykke data, manipulere det, og deretter returnere det tilbake til WordPress før det blir gjort til nettleseren.
For eksempel, hvis du tar en titt på innholdet filter, så vil du legge merke til at hvis du hekker en funksjon i denne handlingen, vil funksjonen din bli gitt innholdet. Dette betyr at du vil kunne manipulere innholdet ved å sette inn informasjon i det, fjerne informasjon fra det eller noe lignende før du sender det tilbake til WordPress for å gjengi til nettleseren.
Tilsvarende oppsummerte jeg filtre i min serie om handlinger og filtre som følgende:
Filtre er funksjoner som WordPress passerer data gjennom under visse punkter i sidens livssyklus. De er primært ansvarlige for å avskjære, administrere og returnere data før de gjøres til nettleseren eller lagrer data fra nettleseren til databasen.
Så med alt det som er sagt, er handlinger og filtre både typer hendelser som oppstår i WordPress-livssyklusen som tillater oss å krok inn i dem og sett inn vår egen kode for utførelse før du får den gjengitt til nettleseren.
Kort sagt er begrepet "kroker" et generelt begrep som refererer til både handlinger og filtre som hver har en annen hensikt.
Nå er en av de vanligste tingene jeg har sett fra folk som kommer fra en annen bakgrunn som Rails, CakePHP, ASP.NET eller andre MVC-rammer, hvordan å kartlegge deres konseptuelle modell av MVC til event- drevet modell av WordPress.
Dermed mener jeg at de prøver å finne analogier til modeller, synspunkter og kontrollører i det eventdrevne paradigmet. For eksempel kan noen prøve å gjøre følgende:
Til det formål anbefaler jeg sterkt å unngå å tenke på WordPress i sammenheng med et annet mønster. Den har sitt eget mønster. Tenk på det i disse termer.
Kort sagt, å komme til WordPress fra et annet rammeverk som bruker et annet designmønster eller et annet paradigme, er bra, men det handler ikke om å gjøre WordPress tilpas din tidligere erfaring.
Du kan ikke ettermontere ett designmønster i en annen og forvente å ha høye kvalitetsresultater.
Programvaren virker ikke slik.
I stedet, akkurat som du gjør med andre rammer, du må tenk når det gjelder hvordan WordPress fungerer for å ordentlig bygge ting på - og for - WordPress. Senere i serien, tar vi en titt på hvorfor WordPress er et solid alternativ for webapplikasjoner, men før det synes jeg det er viktig å forstå mønsteret som WordPress implementerer og hvordan man best kan utnytte det.
I neste innlegg ser vi på noen få eksempler på hvordan vi kan koble til hendelser fra WordPress. Disse vil være veldig innledende og mest erfarne WordPress-utviklere vil trolig allerede vite mange av dem; Det vil imidlertid gi et solidt sett eksempler på hvordan handlinger og filtre - og dermed hendelser - fungerer i WordPress.
Deretter fortsetter vi diskusjonen om funksjonene og fasilitetene som WordPress tilbyr for å bygge webapplikasjoner.
Accentsconagua