Refactoring des Plugins Staticpages Teil 2

Ich gehe nun wieder von oben durch den Quelltext und stelle fest, dass in der Methode selectPageTypes() wieder eine überflüssige foreach-Schleife ist. Wieso? Wir können der Funktion serendipity_db_query() bereits als Parameter mitgeben, welchen Schlüssel und welchen Wert das Array haben soll, was diese Funktion zurückgibt. Dadurch können wir uns anschließend die foreach-Schleife sparen, die genau dieses macht. Führen wir also Refactoringschritt Nummer fünf aus.

Was haben wir an dieser Stelle gesehen? Um seine Software zu optimieren, sollte man auch die Funktionen kennen, die bereits existieren. Wenn man sie selbst programmiert hat sollte man in der Regel wissen, wie man diese anwendet. Anderenfalls sollte eine gute Dokumentation im Quelltext oder in der Nähe vom Arbeitsplatz liegen.

Wehrend ich nun zu meinem eigentlichen Ziel, den Methoden für den Formularaufbau, runterscrolle, fallen mir die Methoden move_up() und move_down() auf. Der einzige Unterschied zwischen den beiden Methoden ist das Plus bzw. das Minus vor der 1. Bevor es nun also zu meinem eigentlichen Ziel geht, optimieren wir auch dieses Problem (Schritt 6).

In Serendipity 1.1 wird es eine spezielle Methode in der Datei plugin_api_extended.php geben, die das nach oben und unten Verschieben von Einträgen in der Datenbank übernimmt. Der Abwärtskompatibilität des Staticpages-Plugin wegen werde ich aber die beiden existierenden Methoden zu einer umschreiben und auf die Nutzung dieser neuen 1.1er spezifischen Funktion verzichten. Für Projekte, wo Abwärtskompatibliltät nicht wichtig ist, sollte man solche Funktionen aber nutzen. Somit kann ein auftretender Fehler an einer Stelle behoben werden und man muss sich nicht durch alle Plugins quälen. (Wer die Funktionsweise der neuen Methode ansehen möchte, sollte sich die aktelle Alpha von Serendipity installieren und mal einen Blick auf das Plugin serendipity_event_mediadbfrontend werfen, zu finden unter http://s9y-cms.fadoe.de).

Kümmern wir uns endlich um die Formularfunktionen. Um über diese einen besseren Überblick zu erhalten und diese vergleichen zu können, kopiere ich showForm() und showTypeForm() in eine eigene Datei und schaue mir diese mit Kompare an.

Interessant sind in diesen Methoden die jeweilige foreach-Schleife. Mit dieser wird das Klassen-Array durchlaufen, was die einzelnen Felder des Formulars enthält. Dieses Array können wir als erstes als Parameter der Funktion übergeben. Als zweites fällt das Array auf, in dem wir die einzelnen Werte für die Felder speichern. Auch das übergeben wir als Parameter. Auch die Introspect-Methode ist für jedes Array unterschiedlich. Also müssen wir auch diese als Parameter übergeben. Mit einigen kleinen Anpassungen könne wir nun die Methode showForm() für das Type-Formular einsetzen.

Natürlich sind wir hier noch nicht fertig. Wir können noch an vielen Orten Verbesserungsmöglichkeiten finden. Es gibt immerhin nichts, was man nicht noch besser machen kann. Doch bevor es weiter geht, lassen wir uns noch einige Überlegungen anstellen.

Wozu dient eigentlich das Plugin serendipity_event_staticpage? Es dient dazu, statische Seiten anzuzeigen und zu erstellen. Nun kann man sich die Frage stellen, ob die Methoden, die für das lesen und speichern der Daten für statische Seiten verantwortlich sind, nicht zusammengefasst und in eine eigene Klasse ausgelagert werden könnten. Das Plugin wäre nur noch für die "Entgegennahme" und Ausgabe der Daten zuständig und eine Klasse "Staticpages" für das lesen und schreiben. Weiterhin könnte man die Klasse "Staticpages" anschließend in andere Plugins integrieren.
Dagegen spricht aber, das ein weiteres Objekt, nämlich die Klasse "Staticpages" zur Laufzeit in den RAM geladen werden müsste. Dies bedeutet mehr Speicherverbrauch, ergo langsamere Reaktionszeiten. Ein weiterer Nachteil ist, dass Serendipity in PHP4 geschrieben und auch auf Webspace mit PHP4 eingesetzt wird. In PHP4 war das Arbeiten mit Klassen noch nicht so komfortabel wie man es sich als Programmierer wünschen würde. Da ich schon einmal auf die Abwärtskompatibilität geachtet habe, werde ich auch diesmal die Methoden, die mit dem statischen Inhalt arbeiten, nicht auslagern.

Nach der Theorie beende ich nun auch diesen Artikel. Die kompletten Quelltexte gibt es wieder am Ende des Artikels. Angemerkt seien noch zwei Dinge: Was ich bis jetzt gemacht habe, muss nicht das optimale sein. Ich bin ja noch am Üben. Und das Zweite: Wer Fragen oder Anmerkungen hat, möge sie einfach schreiben .

staticpages_refactoring_teil2.tar.gz