Share
In deze serie zijn we aan het praten over hoe we webtoepassingen kunnen bouwen met behulp van WordPress. En hoewel dit geen technische serie is waarin we naar code kijken, wij zijn onderwerpen behandelen, zoals kaders, stichtingen, ontwerppatronen, architecturen, enzovoort.
Als je het eerste bericht in de serie nog niet hebt gelezen, raad ik het aan; Voor de doeleinden van deze post kunnen we de vorige post echter als volgt samenvatten:
Kort gezegd, software kan op frameworks worden gebouwd, software kan funderingen verlengen.
Simpel gezegd, we maakten onderscheid tussen raamwerken en stichtingen - twee termen die vaak door elkaar worden gebruikt in software ondanks het feit dat ze niet hetzelfde zijn. WordPress is een basis omdat het een toepassing op zichzelf is. Het is geen raamwerk.
Daarom moeten we, als het gaat om het bouwen van webapplicaties op WordPress, de architectuur opnieuw bekijken of onze conceptuele modellen opnieuw bekijken voor de manier waarop applicaties worden gebouwd.
Op het hoogst mogelijke niveau zijn webapplicaties normaal gestructureerd met de volgende drie componenten:
Over het algemeen is de presentatielaag wat de gebruiker ziet en waarmee de gebruiker communiceert. Het bevat alle stijlen, client-side code en markup nodig om iets voor de gebruiker te plaatsen.
Wanneer de gebruiker op iets klikt of de pagina informatie uit de database haalt, werkt het samen met de applicatielaag.
De applicatielaag is verantwoordelijk voor het coördineren van informatie van de browser en / of van de actie van de gebruiker naar de database. Soms bestaat dit uit het schrijven van informatie naar de database - zoals informatie uit een formulierveld - naar het lezen van informatie uit de database, zoals het ophalen van de accountgegevens van een gebruiker.
Net zoals de Presentation Layer uit verschillende componenten bestaat, zoals stijlen, JavaScript, markup, enzovoort, kan de Application Layer bestaan uit een verscheidenheid aan verschillende componenten, zoals systemen die nodig zijn voor het lezen en schrijven van gegevens in de database, het ontsmetten van informatie , het valideren van informatie en het afdwingen van bepaalde regels die uniek zijn voor het probleem bij de hand.
Ten slotte is de Database Layer waar de gegevens worden opgeslagen. Dat kan uit het bestandssysteem bestaan, het kan uit een MySQL-database bestaan of uit een oplossing van derden, zoals een datastore die "in de cloud" is, zoals Amazon S3 of iets dergelijks.
Het belangrijkste punt om hier afstand van te nemen, is dat we in software altijd te maken hebben met een niveau van abstractie. We praten bijvoorbeeld over de gegevensopslag of de databaselaag, maar we zijn niet echt specifiek. Hetzelfde geldt voor de applicatielaag en de presentatielaag.
Het is duidelijk dat we momenteel niet op zoek zijn naar antwoorden op deze vragen, maar het gaat erom dat alle webtoepassingen uit vergelijkbare componenten bestaan, maar de details van elke component variëren van project tot project.
Als webapplicatie is WordPress een perfect voorbeeld van hoe verschillende technologieën samen een webtoepassing vormen:
Dus dat is de WordPress-architectuur, maar hoe zit het met de projecten die we bovenop de applicatie willen bouwen? Hoe volgen ze dezelfde architectuur?
Wel, onthoud dat WordPress een fundament is - geen raamwerk - dus we zijn standaard onderworpen aan de architectuur van WordPress. Dit doet niet betekent dat we in sommige gevallen onze eigen bibliotheken niet kunnen binnenhalen, maar het heeft wel invloed op de manier waarop onze applicaties en projecten worden gebouwd.
We zullen het wat meer hebben over de bibliotheken, uitbreidbaarheid en meer, maar in de eerste plaats is het van belang op te merken dat MVC (en MVVM en andere varianten van het Model, View, Whatever) -paradigma allemaal dagdagelijks zijn de woede, WordPress doet het niet volg die conventie.
Er zijn argumenten voor en tegen waarom dat een goede zaak of een slechte zaak is, maar dat is niet het doel van deze functie. In plaats daarvan is het gewoon de moeite waard om op te merken dat WordPress een door gebeurtenissen aangestuurd patroon gebruikt in plaats van het configuratiescherm met modelaanzicht.
En om dat te bereiken, is het de moeite waard om te begrijpen hoe het evenementgestuurde model werkt, zodat je een duidelijk begrip hebt van hoe WordPress-hooks werken, en hoe je kunt veranderen van denken vanuit MVC of welk ander paradigma je ook gewend bent te gebruiken, hoe WordPress zijn informatie beheert.
Voordat we een voorbeeld van een evenementgestuurde toepassing bekijken, laten we opnieuw bekijken wat het betekent om het MVC-paradigma te volgen.
Het hele MVC-model ziet er als volgt uit:
Gebeurtenisgestuurde applicaties kunnen nu enkele van dezelfde componenten hebben - dat wil zeggen, ze kunnen weergaven en modellen of views en data-objecten hebben - maar ze hebben niet noodzakelijk een controller die de coördinerende informatie van de voorkant tot de achterkant coördineert.
In plaats daarvan werkt evenementgestuurde programmering van het uitgangspunt dat "zoiets is gebeurd". Vandaar de naam voor acties in het WordPress-jargon (natuurlijk hebben we ook filters, maar ik zal die even behandelen).
WordPress biedt haken die letterlijk punten in uitvoering zijn waarin we onze eigen functionaliteit zodanig kunnen introduceren dat WordPress herkent dat "wanneer deze gebeurtenis gebeurt er, ik moet schieten deze functies"waar deze functies worden gedefinieerd als alles wat we hebben verstrekt.
De waarheid is, filters werken op dezelfde manier, maar hun doel is anders. Kort gezegd, filters zijn acties die zijn bedoeld voor het manipuleren van gegevens (zoals toevoegen, voorverdelen, verwijderen of bijwerken van de inhoud) op een of andere manier voordat ze terugkeren naar de uitvoering van de toepassing.
Dus hoe ziet dit eruit?
Niets erg ingewikkelds, toch?
Het doel van dit artikel is om ons in eerste instantie te laten denken in termen van door gebeurtenissen gestuurde programmering en hoe we onze inspanningen voor het bouwen van webtoepassingen specifiek op WordPress kunnen coördineren..
Dat wil zeggen dat het belangrijk is voor ons om te denken in termen van events of het feit dat 'er iets is gebeurd', zodat we weten wanneer we onze eigen acties op de juiste manier moeten invoegen. We zullen hier in het volgende artikel iets meer in detail over praten, maar het belangrijkste punt dat ik wil dat jullie weghalen van dit specifieke artikel is dat alleen omdat iets niet MVC is (of wat dan ook, het volgende populaire paradigma is ) betekent niet dat het niet goed geschikt is voor de ontwikkeling van toepassingen.
Elk patroon en elke architectuur biedt ons voordelen en nadelen die allemaal kunnen bijdragen aan het succes van het bouwen van een webtoepassing.
Vervolgens nemen we in de reeks een meer gedetailleerde beschrijving van hoe haken een cruciale rol spelen bij het bouwen van webtoepassingen op WordPress, en daarna gaan we kijken naar enkele van de faciliteiten die WordPress out-of-the-box biedt. dat maakt het zo'n solide optie voor bepaalde typen (lees: niet allemaal typen) van webapplicaties.
Accentsconagua