Share
Met mensen die het potentieel van WordPress als een applicatiebasis beginnen te realiseren in plaats van alleen een contentmanagementsysteem of een blogplatform, richt deze serie zich op hoe WordPress voor dergelijke projecten kan worden gebruikt.
Een van de belangrijkste dingen om op te merken is dat WordPress niet bedoeld is als de definitieve oplossing voor het bouwen van webapplicaties. Sterker nog, ik denk niet ieder stichting of kader is bedoeld om te zijn de definitieve oplossing.
In plaats daarvan hebben we een aantal verschillende keuzes, die zich allemaal lenen voor betere situaties dan andere, en WordPress is niet anders. In deze serie gaan we door met het bekijken hoe webapplicaties kunnen worden gebouwd met WordPress en welke situaties zich het best lenen voor de stichting. We moeten echter onze discussie voortzetten over hoe WordPress werkt, zodat we kunnen beginnen te praten over hoe we er applicaties bovenop kunnen bouwen.
In het vorige artikel hebben we besproken hoeveel frameworks een MVC-benadering bieden voor ontwikkeling, maar we hebben ook gekeken naar het door gebeurtenissen gestuurde model van WordPress. In deze post gaan we dieper in op het gebeurtenisgestuurde paradigma dat WordPress gebruikt en waarom dit ertoe doet.
De waarheid is dat veel mensen bekend zijn met dit paradigma, ze zijn gewoon niet bekend met de naamgevingsconventies. Aan het einde van dit artikel zouden we een duidelijk begrip moeten hebben van wat event-driven programmeren is, hoe het werkt, hoe het geïmplementeerd is in WordPress en hoe we hierover moeten nadenken als we van andere patronen komen, zoals Model-View. -Controller.
In het laatste bericht hebben we event-driven programming samengevat met het volgende idee:
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).
En dat is prima voor een werkende definitie van evenementen, vooral op een hoog niveau. Als je echter een meer diepgaande kijk wilt hebben op hoe dit eruit ziet vanuit een praktisch standpunt - dat wil zeggen, hoe WordPress het implementeert - dan is het misschien het beste wat je kunt doen is begrijpen events.
Maar zelfs meer dan dat, het is belangrijk om de levenscyclus van de WordPress-pagina te begrijpen, waar gebeurtenissen plaatsvinden en hoe wij - als ontwikkelaars - eraan kunnen werken om een bepaalde taak uit te voeren.
Zoals we al vermeldden, is het idee van evenementen in event-driven programmeren eenvoudig dat er is iets gebeurd. We blijven dat herhalen, maar wat betekent dat eigenlijk??
In de context van het laden van één pagina zijn er een aantal dingen die optreden:
Al deze kunnen worden beschouwd als evenementen, maar elk van deze is samengesteld uit hun eigen reeks kleinere evenementen - dat wil zeggen, je kunt krijgen werkelijk gedetailleerd over wanneer er iets gebeurt.
Neem bijvoorbeeld het idee om een typisch, openbaar gericht verzoek voor een door WordPress gevoede pagina weer te geven. Als je naar het bijbehorende Codex-document kijkt, zul je merken dat er ongeveer 50 acties plaatsvinden, en dit is het geval niet neem ook post- of pagina-specifieke acties op.
Elk van deze acties kan als een gebeurtenis worden beschouwd, en in de wereld van gebeurtenisgestuurde programmering worden gebeurtenissen gewoonlijk zo belicht dat ze ons eraan kunnen koppelen en informatie kunnen manipuleren voordat deze aan de klant wordt weergegeven..
Vandaar de naam voor haken.
Natuurlijk zijn er in WordPress twee soorten haken: Acties en Filters. Hoewel deze serie niet over een solide tutorial over elk van deze gaat, is het is belangrijk om het verschil in hen te herkennen als ze betrekking hebben op het werken met WordPress.
Acties zijn een soort haak die betekent dat er iets is gebeurd, en wanneer dat iets komt voor, we hebben de mogelijkheid om onze eigen functionaliteit zodanig te registreren dat we onze eigen code kunnen injecteren (of zelfs voorkomen dat bepaalde dingen gebeuren).
Zoals ik samenvatte in mijn serie over acties en filters:
Acties zijn gebeurtenissen in de levenscyclus van de WordPress-pagina wanneer bepaalde dingen zijn opgetreden: bepaalde bronnen zijn geladen, bepaalde voorzieningen zijn beschikbaar en, afhankelijk van hoe vroeg de actie plaatsvond, moeten sommige dingen nog worden geladen.
Het is belangrijk om de beschikbare acties te begrijpen, zodat u weet wanneer de beste tijd om aan een bepaalde gebeurtenis deel te nemen, is dat u de prestaties van de pagina niet belemmert, mogelijk andere gegevens die stroomafwaarts komen, vermaalt, of zodat u goed bent de informatie op het juiste tijdstip en op de juiste plaats verwerken.
Filtert daarentegen een type haak waarmee we een bepaald stuk gegevens kunnen ontvangen, manipuleren en vervolgens terugsturen naar WordPress voordat het wordt weergegeven in de browser.
Bijvoorbeeld, als u naar kijkt de inhoud filter, dan zult u merken dat als u een functie aan deze specifieke actie koppelt, uw functie de inhoud zal krijgen. Dit betekent dat je de inhoud kunt manipuleren door er informatie in te voegen, informatie ervan te verwijderen of iets dergelijks, voordat je het teruggeeft aan WordPress om het naar de browser te renderen.
Op dezelfde manier vat ik filters in mijn serie over acties en filters samen als volgt:
Filters zijn functies waarmee WordPress gegevens doorgeeft tijdens bepaalde momenten in de levenscyclus van de pagina. Ze zijn primair verantwoordelijk voor het onderscheppen, beheren en retourneren van gegevens voordat ze worden doorgegeven aan de browser of om gegevens van de browser naar de database op te slaan.
Dus, met dat alles gezegd, acties en filters zijn dat wel beide soorten gebeurtenissen die plaatsvinden binnen de levenscyclus van WordPress die ons in staat stellen om haak erin en voeg onze eigen code in voor uitvoering voordat deze wordt weergegeven aan de browser.
Kortom, de term 'hooks' is een algemene term die verwijst naar beide acties en filters die elk een ander doel dienen.
Nu, een van de meest voorkomende dingen die ik heb gezien van mensen die afkomstig zijn van een andere achtergrond zoals Rails, CakePHP, ASP.NET of andere MVC-frameworks, is hoe ze hun conceptuele MVC-model in kaart kunnen brengen voor het evenement- aangedreven model van WordPress.
Daarmee bedoel ik dat ze analogieën proberen te vinden met modellen, views en controllers in het event-driven paradigma. Sommigen kunnen bijvoorbeeld proberen om het volgende te doen:
Daarom raad ik aan om te proberen te vermijden dat ik over WordPress nadenk in de context van een ander patroon. Het heeft zijn eigen patroon. Zie het in die termen.
Kortom, komen naar WordPress vanuit een ander raamwerk dat een ander ontwerppatroon of een ander paradigma gebruikt, is prima, maar het gaat er niet om dat WordPress bij je vorige ervaring past.
U kunt het ene ontwerppatroon niet achteraf in het andere inbouwen en verwachten van hoge kwaliteit te zijn.
Software werkt niet zo.
In plaats daarvan, net als bij andere raamwerken, jij moet denk in termen van hoe WordPress werkt om dingen goed te bouwen op - en voor - WordPress. Later in de serie zullen we bekijken waarom WordPress een solide optie is voor webapplicaties, maar daarvoor denk ik dat het belangrijk is om het patroon te begrijpen dat WordPress implementeert en hoe je er het beste van kunt profiteren.
In de volgende post zullen we een paar voorbeelden bekijken van hoe we ons kunnen aansluiten bij evenementen die worden aangeboden door WordPress. Deze zullen zeer inleidend zijn en de meeste ervaren WordPress-ontwikkelaars zullen er waarschijnlijk al veel van kennen; het zal echter een solide reeks voorbeelden bieden van hoe acties en filters - en dus gebeurtenissen - in WordPress werken.
Daarna zullen we onze discussie voortzetten over de functies en faciliteiten die WordPress biedt voor het bouwen van webapplicaties.
Accentsconagua