Die Methode __invoke, die ich an jeder Klasse anbringen kann, hat laut php.net folgende Nutzungsmöglichkeit:

Die __invole-Methode wird aufgerufen, wenn ein Skript versucht, ein Objekt als Funktion aufzurufen.

So ab hier stehe ich jetzt auf dem Schlauch, wahrscheinlich gibt es wirklich gute Anwendungsfälle für __invoke. Ich habe leider nur gar, aber so wirklich keine Ahnung, wann ich das mal verwunden könnte. Ich habe auch noch nicht wirklich ernsthaft jemanden dieses Konstrukt im Quellcode so was verwenden sehen. Ok, liegt vielleicht auch dran, dass es erst ab PHP 5.3 unterstützt wird. Ich finde aber auch keinen guten Artikel im Netz dazu.

So jetzt genug von mir. Das ist eine wirklich ernst gemeinte Frage: Wofür verwendet ihr __invoke?

Im ersten Schritt hat er meine PHP.exe nicht gefunden. Ja richtig ich arbeite mit Windows. Schade eigentlich, naja da habe ich ‘nen Weg drumrum gefunden. Ich habe den Pfad einfach hard reinkodiert, kann man ja mal machen, wenn man was testen will. Soweit hat es dann auch funktioniert.

Dann lief auch alles durch. Nur leider ohne Effekt. Mein Code, der eigentlich klappen sollte, sah so aus:

<?php

include_once 'Process.php';
include_once 'PhpProcess.php';

use Symfony\Components\Process\PhpProcess;

$process = new PhpProcess('C:\Users\phm\websites\phphatesme\test\script.php');
$process->run();

echo $process->getOutput();

Leider bekomme ich als Output nur den Namen des Skripts, dass ich angegeben habe. Tja jetzt stehe ich hier und habe keinen richtigen Artikel. Ich kann aber ein wenig darüber erzählen, was ich eigentlich machen wollte. Im Prinzip ganz einfach. Das Skrtipt skript.php sollte nicht mehr machen, als “hallo welt” ausgeben. Und damit wollte auch mein aufrufendes Skript einfach nur “hallo welt” ausgeben.

Als nächstes hätte ich dann probiert, ob die getOutput Methode nur den endgültigen output des Prozess ausgibt oder auch schon was von der Methode zurückgegeben wird wenn das Skript zwischendurch mal mit flush seine Ausgabe schon mal auf die Kommandozeile pummt. Wäre auf jeden Fall ein cooles Feature, mit dem man bestimmt einiges machen könnte. Vielleicht auch irgendwas streamartiges. Viel Platz für Spielereien. Naja leider ist es dann gar nicht so weit gekommen und eine Doku gibt es auch noch nicht. Wir müssen also unser kleines Prozess-Abenteuer ein wenig verschieben. Falls einer von euch schon weiter gekommen ist, dann hoffe ich mal, dass ihr hier ein wenig Licht ins Dunkel bringt.

Prinzipiell kann man über Extensions einen RSS-Feed erweitern. Was ja eigentlich schön ist. Wenn ich also einen eigenen Namespace für phm haben will, dann schreibe ich mir eine phm-Extension. Diese registriere ich dann beim System. Dummerweise registriere ich die aber nicht bei einer Instanz eines Feed-Writers, sondern wirklich global im System. Jeder RSS-Feed, den ich danach erstelle wird diese Erweiterung auch beinhalten. Zumindest bis ich global den Reset-Knopf drücke. Finde ich schrecklich, weil man keine Ahnung hat,w elche Extensions jetzt wirklich schon registriert sind. Also werde ich natürlich am Anfang ein Reset drücken … und das jedes mal.

Zend_Feed_Writer::registerExtension( 'PhmRss' );

So, das war der erste Punkt, den ich anders machen würde. Merken wir uns: Global ist böse. Machen wir weiter., zwei Punkte habe ich nämlich noch. Der Zend_Writer hat beim initialisieren schon einige Core-Extensions dabei, die mit dem Reset autormatisch hinzugefügt werden. Ist ja nicht schlimm. Kann ja sein, dass es Extensions gibt, die “lebenswichtig” sind. Aber warum zum Teufel wird IMMER die iTunes-Erweiterung hinzugefügt? Und jetzt bitte nicht mit “das hat historische Gründe” kommen. Es sind übrigens noch mehr sinnfreie Standarderweiterungen dabei.

Aller guten Dinge sind doch drei, also brauchen wir auch noch einen dritten Punkt. Kein Problem, den liefert das System von selbst. Wir waren ja gerade bei der iTunes-Implementierung. Nehmen wir an, ich baue eine Erweiterung für phphatesme. Kann ja mal vorkommen. Diese soll das Element “phm:Duration” hinzufügen und füllen. Die Methode bei meiner Externsion heißt dann setPhmRssDuration(). Das dumme daran ist, wenn ich die Methode so nenne, dann wird mir autormatisch das iTunes-Feld Duration auch gefüllt. Warum das? jede Methode wird auf alle registrierten Erweiterungen aufgerufen, deswegen haben sie auch alle eine magische __call Methode, die halt nichts macht, wenn die nötige Methode nicht existiert. Die iTunes-Erweiterung prüft nämlich ob Name der Methode, die aufgerufen wir existiert, indem es die ersten 9 Zeichen abschneidet, ein setItunes oder addItunes davorstellt und ein method_exists aufruft. Tja dummerweise trifft das auf meine setPhmRssDuration() auch zu und somit wird das Feld Duration gefüllt. Dummerweise habe ich dann das itunes:duration Feld im Feed auch mit drinnen. (Wie das genau funktioniert, müsste ich mir aber nich mal angucken, war nur grad so schön um Fluss)

Ach tut das gut sich mal wieder aufzuregen. Ansonsten ist das Zend_Writer System schon ganz nett zu nutzen und an vielen Stellen gut durchdacht. Ich werde die Tage wohl einfach mal erklären, wie man eigene Extensions schreibt, denn dazu habe ich keine gute Doku gefunden.

In meinem gestrigen Fall war das Internet ganz sicher nicht der Hauptschuldige. Ich schiebe es eher Fabien Potencier in die Schuhe. Ja genau, dem “Erfinder” von Symfony. Aber vielleicht hole ich ein wenig weiter aus, denn so einfach ist das nämlich gar nicht. Ich musste für eines unserer Projekte ein Schaubild aufzeichnen, das zeigt, wie eine HTTP-Anfrage durch die Applikation geschleppt wird und dann irgendwann als Response endet. Klingt eigentlich einfach so ein Prozessdiagramm aufzusetzen, wenn man sich in seinen Projekten an den Symfony-Standard hält. Denkste! Ich habe im ganzen Netz gesucht – und ich meine wirklich alle 762545142125434 Seiten. Nichts!

Irgendwie scheint es dieses Schaubild nicht zu geben. Ist es denn wirklich möglich, dass ich der Einzige bin, der so etwas hilfreich findet? Man findet immer nur die folgende Grafik:

Ich habe bis heute nicht verstanden, wie ich dieses Schaubild zu lesen habe. Egal, passt wunderbar zu meiner Laune.  Wahrscheinlich gibt es die ganzen Diagramme und Grafiken unter diagramme.symfony-project.org und ich bin nur zu doof sie zu finden, aber vielleicht eben auch nicht und dann habe ich allen Grund mich aufzuregen.

Geht es euch nicht auch so, dass ihr gerne grafisch aufbereitet eure Architektur vor euch habt? Vielleicht auch noch die einzelnen Schichten in einem weiteren bunten Bildchen. Wie soll ich denn sonst auf Anhieb wissen, was ich darf und was nicht.

Was bedeutet das ganze für mich? Ich werde es selbst machen müssen, falls nicht einer von euch bereits eine Lösung hat. Dann werde ich das Bild nehmen und Monsieur Potencier schicken, so dass er es veröffentlichen kann oder auch nicht.

So heute war der Artikel mal wieder ohne Mehrwert für euch. Aber mir geht es besser. Tut doch manchmal gut, den ganzen Frust rauszulassen und mal wieder festzustellen, dass PHP mich wirklich hasst. Ach ja, vielleicht hat ja jemand Lust mal zu zeigen, welche Standarddiagramme es so in der Softwaretechnik gibt und diese vorstellt. Falls sich niemand findet, dann mache im Notfall ich das auch gerne. Dann habt ihr doch was von diesem Artikel gehabt.

Die letzte Woche bin ich mal wieder über ein mir schon bekanntes Problem mit PHP und empty gestoßen. Mir ist aber aufgefallen, dass ich es noch nie dokumentiert habe und ich dies mal nachholen sollte, bevor ich wieder alles vergessen habe und das Wissen für immer in den Tiefen des Internets verschwindet. Außerdem ist es gut, wenn man es mal gelesen hat und sich dann wieder erinnert.

Wow, schon fast der ganze Artikel rum und ich habe noch kein Wort über das eigentliche Thema geschrieben. Ist auch neuer Rekord im „drumrumreden“. Wobei geht es also heute? PHP verhält sich bei der empty Methode ein wenig anders als man es erwartet, wenn man damit auf magische Methoden losgeht. Ein kleines Beispiel:

class MagicClass
{
	public $theArray = array( '1' );

	public function __get( $name )
	{
		return array( '1' );
	}
}
$magic = new MagicClass();
var_dump( empty( $magic->theArray ) );
var_dump( empty( $magic->theMagicArray ) );

Wir wissen alle, dass die magische __get Methode immer dann aufgerufen wird, wenn man auf ein Attribut lesend zugreift, welches nicht existiert. Wenn man sich das Beispiel anschaut, so müsste beide var_dump ein false zurückliefern. Tun sie aber leider nicht. Der erste Aufruf, mit dem existierenden Attribut liefert natürlich ein false. So weit so gut. Der zweite Aufruf aber leider nicht. Komischerweise wird die magische Methode gar nicht aufgerufen und somit kommt dort etwas leeres zurück und das ist natürlich empty.

Mit ein wenig rumgooglen könnte man jetzt wahrscheinlich rausfinden was genau kaputt ist, da ich aber gerade im Zug von Freiburg nach Hamburg sitze und keinen Internetzugang habe, muss ich das euch oder einem der kommenden Artikel überlassen.

Lösung: Danke erstmal an KingCrunch und Sebastian. Die Lösung des Problems ist einfach. Die empty Funktion erwartet, dass die magische Methode __isset( ) auch mit Leben gefüllt ist, dann klappt das ganze nämlich ohne Probleme.

Fangen wir mal mit der einfachen Seite an. Separation of Concencs (SOC) bedeutet eigentlich nur, dass Funktionalitäten klar voneinander getrennt sind. Konsequenz daraus ist zum Beispiel, dass jede Methode nur genau eine Sache macht. Wenn man diesen Ansatz konsequent verfolgt, steigt auch die Wiederverwendbarkeit der Komponenten. Klingt einach? Finde ich auch. Nur warum zum Teufel beachtet das niemand?

Fast immer wenn ich fremden Code reviewe, finde ich Stellen, an denen es nicht beherzigt wurde kleine Trennungen von Aufgaben zu gewährleisten. Scheint also doch nicht so einfach zu sein ein Gespür dafür zu entwickeln, wann ich denn jetzt SOC betreiben sollte. Mein Fluchen von vorhin war übrigens eher theatralisch gemeint, ich habe früher ja selbst das “Gespür” dafür nicht gehabt. Einigen wir uns also drauf, dass es vielleicht doch nicht so einfach ist.

Was mir immer geholfen hat bei diesem Thema ist eine ganz spezielle Frage. Wo würdest du diese Funktionität vermuten, wenn du sie noch mal brauchen würdest? Am besten dabei in einen anderen Entwickler versetzen. Wenn du ganz bestimmt nicht an der Stelle danach Ausschau halten würdest, an der du es jetzt programmiert hast, dann ist es mit Sicherheit die falsche Position.

Wenn man sich mal ein wenig mit der Firma beschäftigt, dann fällt einem auf, dass sie anscheinend sehr gerne Dinge neu erfinden. Und das nicht nur einmal, sondern öfters. Fangen wir mal an, mit den Dingen, die mir bekannt sind.

Framework

Ok, das ist fies. Symfony ist echt eines der besten Frameworks auf dem Markt und hat bestimmt seine Existenz verdient. Trotzdem haben sie sich hingesetzt und haben für ihre Arbeiten ein „eigenes“ System entworfen.

Unit Test

Tja wenn man entwickelt, dann muss man auch testen. Was nehmen wir denn am besten zum Unit Testing? Ihr meint phpUnit? Nein. Wir schreiben einfach ein neues System namens Lime. Das ist bestimmt eines Tages viel besser als phpUnit. Halten wir uns an xUnit Standards? Ne auch nicht. Finde ich relativ daneben den Ansatz.

Continuous Integration

Ich hatte ja mal vor kurzem einen Artikel geschrieben das Unit Testing nichts wert ist ohne CI. Dazu stehe ich auch immer noch. Ich würde auch sagen, dass es da mit Cruise Control und phpUnderControl sehr gute Systeme gibt, die man nutzen kann. Nein Sensio macht da selbst was intern und verwendet dies.

Pear Channel

Software will ja auch ausgerollt werden. Der PEAR Installer löst da sehr viele Probleme. Das haben auch die Jungs hinter Symfony gedacht und haben sich gleich mal einen eignen PEAR Server gebastelt, der das Ausrollen unterstützt. Doof, oder?

So das waren auch schon die Fakten, von denen ich weiß. Ich will hier jetzt kein Framework gebashe draus machen. Es geht mir einfach nur drum, dass man, wenn man nicht zufrieden ist mit den Lösungen, die der Markt so bietet, sich doch bitteschön hinsetzt und die existierenden Lösungen aufbohrt (entschlackt). Ist ja schließlich alles Open Source, was ich gerade aufgezählt habe. Damit erspart man sich jede Menge arbeit.