Share
In dieser Serie sprechen wir gerade darüber, wie wir Webanwendungen mit WordPress erstellen können. Und obwohl dies keine technische Serie ist, in der wir uns mit Code beschäftigen, sind wir es sind behandelt Themen wie Frameworks, Fundamente, Entwurfsmuster, Architekturen usw..
Wenn Sie den ersten Beitrag der Serie nicht gelesen haben, empfehle ich ihn. Für die Zwecke dieses Beitrags können wir den vorherigen Beitrag jedoch wie folgt zusammenfassen:
Kurz gesagt, Software kann auf Frameworks aufbauen, Software kann Fundamente erweitern.
Einfach ausgedrückt, wir haben zwischen Frameworks und Stiftungen unterschieden - zwei Begriffe, die in der Software oft austauschbar verwendet werden, obwohl sie nicht dasselbe sind. WordPress ist eine Grundlage, weil es eine Anwendung für sich ist. Es ist kein Rahmen.
Zu diesem Zweck müssen wir beim Erstellen von Webanwendungen in WordPress die Architektur überdenken oder unsere konzeptionellen Modelle für die Erstellung von Anwendungen überdenken.
Auf der höchsten Ebene sind Webanwendungen normalerweise mit den folgenden drei Komponenten strukturiert:
Im Allgemeinen ist die Präsentationsschicht das, was der Benutzer sieht und womit er interagiert. Es enthält alle Stile, clientseitigen Code und Markierungen, die erforderlich sind, um dem Benutzer etwas vorzulegen.
Wenn der Benutzer auf etwas klickt oder die Seite Informationen aus der Datenbank abruft, interagiert er mit der Anwendungsebene.
Die Anwendungsebene ist dafür verantwortlich, Informationen vom Browser und / oder von der Aktion des Benutzers an die Datenbank zu koordinieren. Manchmal besteht dies darin, Informationen in die Datenbank zu schreiben (z. B. Informationen aus einem Formularfeld), um Informationen aus der Datenbank zu lesen, z. B. das Abrufen der Kontoinformationen eines Benutzers.
Ähnlich wie der Presentation Layer aus verschiedenen Komponenten besteht (z. B. Stile, JavaScript, Markup usw.), kann der Application Layer aus verschiedenen Komponenten bestehen, beispielsweise aus Systemen, die zum Lesen und Schreiben von Daten in die Datenbank erforderlich sind, um Informationen zu bereinigen , Validieren von Informationen und Durchsetzen bestimmter Regeln, die für das vorliegende Problem spezifisch sind.
Schließlich werden die Daten auf der Datenbankebene gespeichert. Das kann aus dem Dateisystem bestehen, es kann aus einer MySQL-Datenbank bestehen oder aus einer Lösung eines Drittanbieters wie einem Datastore, der "in der Cloud" ist, wie Amazon S3 oder ähnlichem.
Der Hauptpunkt, den wir davon nehmen sollten, ist, dass wir uns in Software immer auf einer Abstraktionsebene befinden. Wir sprechen zum Beispiel über den Datenspeicher oder die Datenbankschicht, aber wir sind nicht wirklich spezifisch. Gleiches gilt für die Anwendungsschicht und die Präsentationsschicht.
Es ist offensichtlich, dass wir derzeit nicht versuchen, Antworten auf diese Fragen zu geben, aber der Punkt ist, dass alle Webanwendungen aus ähnlichen Komponenten bestehen, aber die Details jeder Komponente variieren von Projekt zu Projekt.
Als Webanwendung selbst ist WordPress ein perfektes Beispiel dafür, wie verschiedene Technologien zu einer Webanwendung zusammengefügt werden:
Das ist also die WordPress-Architektur, aber was ist mit den Projekten, die wir auf die Anwendung aufbauen wollen? Wie folgen sie der gleichen Architektur??
Denken Sie daran, dass WordPress eine Grundlage und kein Framework ist. Daher unterliegen wir standardmäßig der Architektur von WordPress. Das macht nicht Das bedeutet, dass wir in einigen Fällen keine eigenen Bibliotheken mitbringen können, aber es beeinflusst die Art und Weise, wie unsere Anwendungen und Projekte erstellt werden.
Wir werden mehr über die Bibliotheken, die Erweiterbarkeit und mehr in Kürze sprechen, aber zuerst ist es wichtig zu wissen, dass in einer Zeit, in der MVC (und MVVM und andere Varianten des Model, View, Whatever) Paradigmas alle sind die Wut tut WordPress nicht folge dieser Konvention.
Es gibt Argumente dafür und dagegen, warum das eine gute oder eine schlechte Sache ist, aber das ist nicht der Zweck dieses Beitrags. Stattdessen ist es einfach erwähnenswert, dass WordPress ein ereignisgesteuertes Muster anstelle des Steuerungsfelds für die Modellansicht verwendet.
Um dies zu erreichen, ist es wichtig zu verstehen, wie das ereignisgesteuerte Modell funktioniert, so dass Sie ein klares Verständnis für die Funktionsweise von WordPress-Hooks haben und wie Sie Ihre Meinung von MVC oder dem von Ihnen verwendeten Paradigma ändern können wie WordPress seine Informationen verwaltet.
Bevor wir uns ein Beispiel für eine ereignisgesteuerte Anwendung ansehen, lassen Sie uns noch einmal überlegen, was es bedeutet, dem MVC-Paradigma zu folgen.
Das gesamte MVC-Modell sieht folgendermaßen aus:
Jetzt können ereignisgesteuerte Anwendungen dieselben Komponenten haben, dh sie können über Ansichten und Modelle oder Ansichten und Datenobjekte verfügen. Sie verfügen jedoch nicht notwendigerweise über einen Controller, der Informationen vom Front-End zum Back-End koordiniert.
Stattdessen arbeitet die ereignisgesteuerte Programmierung von der Prämisse ab, dass "etwas passiert ist". Daher der Name für Aktionen in der WordPress-Sprache (natürlich haben wir auch Filter, aber ich werde diese kurz behandeln).
WordPress bietet Hooks, die buchstäblich Punkte in der Ausführung sind, in die wir unsere eigene Funktionalität einführen können, sodass WordPress das "Wann" erkennt diese Veranstaltung passiert, muss ich feuern diese Funktionen" woher diese Funktionen sind definiert als das, was wir zur Verfügung gestellt haben.
Die Wahrheit ist, Filter arbeiten auf dieselbe Weise, aber ihr Zweck ist anders. Filter sind Aktionen, die dazu dienen, Daten zu manipulieren (z. B. Anhängen, Voranstellen, Entfernen oder Aktualisieren des Inhalts), bevor Sie wieder zur Ausführung der Anwendung zurückkehren.
Wie sieht das also aus??
Nichts fürchterlich kompliziert, richtig?
In diesem Artikel geht es in erster Linie darum, in Bezug auf ereignisgesteuerte Programmierung zu denken und wie wir unsere Anstrengungen beim Erstellen von Webanwendungen speziell für WordPress koordinieren können.
Das heißt, es ist wichtig, dass wir in Form von denken Veranstaltungen oder die Tatsache, dass "etwas passiert ist", sodass wir wissen, wann wir unsere eigenen Handlungen angemessen einfügen sollen. Wir werden im nächsten Artikel etwas ausführlicher darüber sprechen, aber der Hauptpunkt, den ich Ihnen von diesem Artikel nehmen möchte, ist, dass etwas nicht MVC ist (oder was auch immer das nächste beliebte Paradigma ist) ) bedeutet nicht, dass es nicht für die Anwendungsentwicklung geeignet ist.
Jedes Muster und jede Architektur bietet uns Vor- und Nachteile, die alle zum Erfolg beim Erstellen einer Webanwendung beitragen können.
Als nächstes in der Serie werden wir uns eingehender damit befassen, wie Hooks eine wichtige Rolle beim Erstellen von Webanwendungen in WordPress spielen, und dann werden wir uns einige der Möglichkeiten ansehen, die WordPress standardmäßig bietet das macht es zu einer soliden Option für bestimmte Typen (lesen Sie: nicht alles Typen) von Webanwendungen.
Accentsconagua