Rapid Prototyping: Vom Prototyp zum Code, Teil 1

Was Rapid Prototyping und WordPress betrifft, haben wir bisher zwei Dinge getan:

1. das Plugin geplant ,
2. skizzierte ein Diagramm, wie der Code organisiert werden kann

An diesem Punkt haben wir genug Arbeit geleistet, um den Beginn der Umgestaltung unseres Codes zu rechtfertigen. Das heißt, wir beginnen mit der Umwandlung des Prototyps in Code. Aber das ist etwas, was in zwei Phasen geschehen muss.

Zuerst werden wir einfach Klassen einführen, die die Diagramme aus dem vorherigen Post darstellen und die Verantwortung jedes Projekts kapseln.

Danach werden wir uns mit der Organisation des Codes in Namespaces und Paketen befassen. Bevor wir das tun können, müssen wir jedoch sicherstellen, dass der Code objektorientiert ist und funktionsfähig bleibt. Darum geht es in diesem Beitrag.

Vom Prototyp zum Code

Wenn Sie die vorherigen Posts gelesen haben, beachten Sie, dass ich vorhabe, der Organisation zu folgen, die ich im letzten Post skizziert habe. Sie müssen sich natürlich nicht an dieses spezielle Design halten.

Ein Wort zur Quellcodeverwaltung

Wenn Sie die Quellcodeverwaltung verwenden, empfehle ich hier, einen Branch vom Master-Branch zu erstellen (wenn Sie Git verwenden), damit Sie Ihre Arbeit erledigen können, ohne die stabile Version des Codes zu beeinträchtigen.

Dies geht etwas über den Rahmen der Serie hinaus, also keine Sorge, wenn Sie die Quellcodeverwaltung nicht verwenden. Wenn ja, entscheide ich mich für den Namen dieses Zweigs. Ich werde es wieder in Master  zusammenführen, sobald ich sicher bin, dass es funktioniert.

Code schreiben

Gemäß der gestern skizzierten Arbeit werde ich zwei Klassen erstellen:

1. die Meta-Box-Klasse,
2. die Meta-Box-Anzeigeklasse.

Es wird eine gewisse Codewiederverwendung von dem geben, was wir bereits gesehen haben, wie Sie im folgenden Code sehen werden.

Der Code

Zuerst unsere Metabox :

Und als nächstes unsere Anzeige :

Dass wir im Meta-Box-Code die Anzeige explizit instanziieren, damit wir bei Bedarf ihre Anzeigemethode aufrufen können.

Eine andere Alternative wäre, die beiden Objekte separat zu instanziieren und dann die Anzeige per Konstruktorinjektion oder ähnlichem in die Metabox einzufügen. Dies müsste in einer Klasse eines Drittanbieters erfolgen.

Die Vorteile ergeben sich aus der etwas stärkeren Entkopplung der beiden Klassen. Vielleicht sehen wir uns im nächsten Beitrag an, wie das geht.

Danach müssen wir fortfahren und die Klasse definieren, die für die Anzeige von Nachrichten im Kontext der Meta-Box-Anzeige verantwortlich ist. Dies nennen wir den Post-Messenger :

Beachten Sie hier, dass der Post Messenger auch auf die Post Query verweist. Dies ist die Klasse, in der die Kommunikation mit der Datenbank stattfindet. Ich habe auch ein paar Hilfsfunktionen eingefügt, um den Ansichtscode etwas einfacher zu machen, wie wir gleich sehen werden.

Und das war’s für die Kernklassen. Natürlich müssen wir noch über die Ansichten sprechen.

Die Ansichten

Die Ansichten sind für das Rendern des HTML im Kontext der Metabox verantwortlich. Ich mag es nicht, HTML im Kontext von PHP zu schreiben (ich mag es auch nicht, PHP im Kontext von HTML zu mischen, aber das ist in diesem Projekt unvermeidlich).

Es gibt einige großartige Templating-Projekte, um dies zu vereinfachen, aber ich schweife ab. Wie auch immer, Sie werden feststellen, dass es in der  Datei post-list.php Verweise auf Hilfsfunktionen in der Klasse Post Query gibt. Damit soll sichergestellt werden, dass ich nicht zu viele Grundstücke preisgebe und gegen das Demeter-Gesetz verstoße.

Schauen wir uns zuerst diese Datei an, da sie die komplizierteste ist :

Es sieht aus wie dieser Standard-WordPress-Code, aber denken Sie daran, dass diese Datei, da sie innerhalb des Post Messenger aufgerufen wird, auf die Abfrage als die Abfrage verweist, die von dieser Klasse umschlossen ist.

Die letzten beiden Dateien sind ziemlich geradlinig. Einer von ihnen liefert eine Beschreibung :

Der andere liefert eine Nachricht, wenn keine Beiträge vorhanden sind :

Ansonsten ist die Grundfunktionalität erledigt.

Bootstrapping des Plugins

Als letztes müssen wir das Plugin starten. Dazu ändern wir den Code in der Haupt-Plugin-Datei so ab, dass er so aussieht :

Das wird sich in WordPress einklinken, unser Plugin instanziieren und es dann in Gang setzen. Wenn Sie es in Ihrer Installation von WordPress ausführen, sollte es genauso aussehen wie in der ersten Version.

Der einzige Unterschied besteht darin, dass wir die Dinge jetzt in Klassen und nicht mehr in einzelnen Funktionen organisiert haben.

Anmerkungen

Erstens gibt es hier Möglichkeiten zum Refactoring, die die Entkopplung noch weiter reduzieren würden (z. B. verschiedene Arten von Dependency Injection usw.), aber der Zweck dieser Serie besteht nicht darin, dies zu behandeln.

Stattdessen geht es darum, Plugins zu sehen, die von vielen prozeduralen Funktionen geschrieben wurden, und sie dann in konzeptionellere Klassen aufzuteilen, die ihre Verantwortlichkeiten kapseln.

Zweitens, wenn Sie den Quellcode im Repository für diese Version des Projekts überprüfen, werden Sie feststellen, dass ich auch composer.json eingeführt habe. Auf diese Weise kann ich beim Schreiben von Code PHP CodeSniffer und die WordPress Coding Standards nutzen.

Im letzten Teil der Serie werden wir die Namensräume durchgehen und die Dateien neu organisieren. Wenn es die Zeit erlaubt, fügen wir einen Autoloader hinzu, damit wir Dateien nicht manuell oben in unsere Plugin-Datei einfügen müssen.

Schließlich habe ich diesen Code in Master gemergt und als 0.2.1 gekennzeichnet (da ich einen kleinen Hotfix machen musste), da er immer noch in Arbeit ist.

Serienbeiträge

1. Rapid Prototyping mit WordPress: Vom Konzept zum Plugin
2. Rapid Prototyping mit WordPress: Konzeptanalyse
3. Rapid Prototyping: Vom Prototyp zum Code, Teil 1
4. Rapid Prototyping: Vom Prototyp zum Code, Teil 2
5. Rapid Prototyping: Einführung in das automatische Laden