Share
I den här serien är vi på väg att prata om hur vi kan bygga webbapplikationer med WordPress. Och även om det här inte är en teknisk serie där vi ska titta på kod, vi är som täcker ämnen som ramar, fundament, designmönster, arkitekturer och så vidare.
Om du inte har läst det första inlägget i serien rekommenderar jag det; För det här inlägget kan vi dock sammanfatta föregående inlägg enligt följande:
Kort sagt kan programvara byggas på ramar, mjukvaran kan förlänga grunden.
Enkelt uttryckt skilde vi mellan ramar och stiftelser - två termer som ofta används omväxlande i programvara trots att de inte är samma sak. WordPress är en grund för att det är en applikation för sig själv. Det är inte en ram.
För det ändamålet, när det gäller att bygga webbapplikationer på WordPress, måste vi ompröva arkitekturen eller ompröva våra konceptuella modeller för hur applikationer byggs.
På höga nivåer är webapplikationer normalt strukturerad med följande tre komponenter:
Generellt sett är Presentation Layer vad användaren ser och vad användaren interagerar med. Den innehåller alla stilar, klientsidkod och markup som är nödvändiga för att sätta något framför användaren.
När användaren klickar på något, eller sidan ger information som hämtas från databasen, samverkar den med applikationslagret.
Applikationslagret ansvarar för att samordna information från webbläsaren och / eller från användarens åtgärd till databasen. Ibland består detta av att skriva information till databasen - till exempel information från ett formulärfält - för att läsa information från databasen, som att hämta en användares kontouppgifter.
Såsom Presentation Layer består av olika komponenter - till exempel stilar, JavaScript, markup osv. - Applikationslagret kan bestå av en mängd olika komponenter, t.ex. system som är nödvändiga för att läsa och skriva data till databasen, sanering av information , validering av information och tillämpning av vissa regler som är unika för det aktuella problemet.
Slutligen är databaslagret där data lagras. Det kan bestå av filsystemet, det kan bestå av en MySQL-databas, eller det kan bestå av en tredjepartslösning som en datastore som är "i molnet" som Amazon S3 eller något liknande.
Huvuddelen att ta bort från detta är att i mjukvaran handlar vi alltid om någon grad av abstraktion. Vi pratar till exempel om datalagret eller databaslagret, men vi är inte riktigt specifika. Samma sak gäller applikationslagret och presentationslagret.
Självklart ser vi inte ut att svara på dessa frågor just nu, men poängen är att alla webbapplikationer består av liknande komponenter, men detaljerna i varje komponent varierar från projekt till projekt.
Som en webbapplikation är WordPress ett perfekt exempel på hur olika teknologier kommer samman för att bilda en webbapplikation:
Så det är WordPress-arkitekturen, men hur är det med de projekt som vi vill bygga ovanpå applikationen? Hur följer de samma arkitektur?
Tja, kom ihåg att WordPress är en grund - inte en ram - så vi är vanligtvis utsatt för WordPress 'arkitektur. Detta gör det inte betyder att vi inte kan ta med egna biblioteken i vissa fall men det påverkar hur våra applikationer och projekt byggs.
Vi talar mer om biblioteken, utökningsbarhet och lite mer, men först är det viktigt att notera att i en dag och ålder där MVC (och MVVM och andra varianter av modellen, View, What) paradigmet är alla raseri, WordPress gör det inte följ den konventionen.
Det finns argument för och mot varför det kan vara bra eller dåligt, men det är inte syftet med detta inlägg. Istället är det helt enkelt värt att notera att WordPress använder ett händelsestyrt mönster, snarare än modellvyn-kontrollpanelen.
Och för det ändamålet är det värt att förstå hur den händelsesdrivna modellen fungerar så att du har en klar förståelse för hur WordPress-krokar fungerar och hur du kan flytta du tänker från MVC eller vilket annat paradigm du brukar använda, till hur WordPress hanterar sin information.
Innan vi tittar på ett exempel på en händelsesdriven applikation, låt oss se över vad det innebär att följa MVC-paradigmet.
Hela MVC-modellen ser så här ut:
Nu kan händelsesdrivna applikationer ha några av samma komponenter - det vill säga de kan ha synpunkter och modeller eller synpunkter och dataobjekt - men de behöver inte nödvändigtvis en kontroller som samordnar information från frontänden till bakre änden.
I stället fungerar händelsesdriven programmering utifrån premissen att "något som hände." Därför namnet för åtgärder i WordPress lingo (naturligtvis har vi också filter, men jag täcker dem kort).
WordPress ger krokar som bokstavligen pekar på utförandet där vi kan presentera vår egen funktionalitet så att WordPress känner igen "när den här tillställningen händer, jag måste elda dessa funktioner" var dessa funktioner definieras som vad vi har angivit.
Sanningen är att filter fungerar på samma sätt, men deras syfte är annorlunda. Kortfattat är filter handlingar som är avsedda att manipulera data (till exempel lägga till, lägga ut, ta bort eller uppdatera innehållet) på något sätt innan de återvänder till programmets körning.
Så hur ser det ut här?
Inget hemskt komplicerat, rätt?
Punktet i den här artikeln får oss framför allt att tänka i händelsestyrd programmering och hur vi samordnar våra ansträngningar att bygga webbapplikationer specifikt på WordPress.
Det vill säga att det är viktigt för oss att tänka i termer av evenemang eller det faktum att "något har hänt" så att vi vet när vi ska infoga våra egna handlingar på lämpligt sätt. Vi kommer att prata lite om det här i detalj i nästa artikel, men den viktigaste punkten som jag vill att ni ska ta bort från den här artikeln är att bara för att något inte är MVC (eller vad det nuvarande populära paradigmet är ) betyder inte att det inte är väl lämpat för applikationsutveckling.
Varje mönster och arkitektur ger oss fördelar och nackdelar som alla kan bidra till framgången med att bygga en webbapplikation.
Nästa upp i serien tar vi en mer detaljerad titt på hur krokar spelar en viktig roll för att bygga webbapplikationer på WordPress, och sedan börjar vi titta på några av de faciliteter som WordPress erbjuder out-of-the-box som gör det så solidt alternativ för vissa typer (läs: inte Allt typer) av webbapplikationer.
Accentsconagua