In PHP 5.3 wurden Closures, auch als anonyme Funktionen bekannt, eingeführt. Wer schon einmal DOM-Manipulationen in JavaScript durchgeführt hat, wird sicher schon über dieses Konzept gestolpert sein. Closures sind nichts anderes als Funktionen ohne einen Bezeichner. Am Sinnvollsten verwendet man Closures Als Callback-Funktionen.
Nehmen wir an, wir haben ein kleines Script und wollen einen eigenen error-handler verwenden. Bisher ist man wie folgt vorgegangen:
Mittlerweile findet die Dependency Injection – kurz DI – auch in der PHP-Welt immer mehr Verbreitung. Dennoch möchte dieses Entwurfsmuster hier noch einmal vorstellen. Ziel von DI ist es, Abhängigkeiten zwischen Objekten zu minimieren und im Idealfall eine erhöhte Wiederverwendbarkeit von Klassen zu ermöglichen.
Bisher wurden Abhängigkeiten zu anderen Objekten, beispielsweise bei einer Aggregation, von dem “übergeordneten” Objekts aufgelöst. Dazu wiederrum benötigt ein Objekt Kenntnisse über das zu erzeugende Objekt und dessen Implementierung. Folgendes Beispiel soll dies noch ein mal veranschaulichen:
<?php
class Car {
private $engine = null;
public function __construct() {
$this->engine = new Engine();
}
}
Bei der Dependency Injection Entzieht man nun den Objekte die Verantwortung, Abhängigkeiten aufzulösen. Stattdessen erzeugt nun der Entwickler die benötigten Objekte und teilt beispielsweise dem Objekt vom Typ Car mit, welches Objekt vom Typ Engine es nutzen soll:
<?php $Engine = new Engine(); $Car = new Car($Engine);
Ein Vorteil sollte hier schon erkennbar sein. Es ist nun theoretisch möglich, der Car-Instanz einen anderen Motor zu übergeben. Es müssen nur die gleichen Methoden vorhanden sein. Sollte man, um beim Beispiel zu bleiben, allerdings einen Motor eines Drittanbieters verwenden wollen, wird man nicht um das Schreiben einer Adapter-Klasse herumkommen.
Die Abhängigkeiten können über den Konstruktor, aber auch über Setter oder direkt an eine Objekteigenschaft, injiziert werden. Es gibt eine Faustregel, wann man welche der Möglichkeiten nutzen sollte:
Eine Erweiterung des Entwurfsmusters sind Frameworks oder auch DI Container wie z.B. Symfony Dependency Injection. In diesen Containern werden alle Abhängigkeiten definiert und anschließend automatisiert aufgebaut. Solche Frameworks sind aber in der Regel nur dann Sinnvoll, wenn man mit vielen unterschiedlichen Objekten mit vielen Abhängigkeiten arbeitet. In den meisten Fällen sollte jedoch eine manuelle Dependency Injection ausreichend sein 
.
Bei einem aktuellen Projekt können sich Benutzer ein Profil anlegen und müssen dazu ein Bild hochladen. Nach dem erfolgreichen Upload werden die Bilder auf eine einheitliche Größe resized und im PNG-Format gespeichert. An sich nichts besonderes. Laut den Anforderungen sollen die Formate JPG, PNG, GIF und BMP unterstüzt werden.
Das letztere Format ist jedoch ein kleiner Fallstrick. So trat der Fall auf, dass ich aus dem BMP kein resized PNG erzeugen konnte. Der Fehler war auch schnell gefunden. Ich nutzte sowohl für BMP wie auch für WBMP die PHP-Funktion imagecreatefromwbmp(). Jedoch steht das W in WBMP nicht etwa für Windows, sondern für Wireless – ein Grafikformat, welches speziell für Mobiltelefone entwickelt wurde. Ein PC-Bitmap kann mir der Funktion nicht verarbeitet werden und PHP stellt keine native Funktion dafür bereit.
Die Lösung findet sich aber glücklicherweise, über mehrere Kommentare verteilt, auf der Doku-Seite zu imagecreatefromwbmp(), welche ich hier nochmal zusammengefasst bereitstellen möchte.
Wer mit PHP einen Fileupload umsetzt, prüft (hoffentlich) auf eventuell aufgetretene Fehler. Dazu gibt es ein paar Konstanten gegen die man prüfen kann und so erfährt, was nun schief ging. Bisher waren mir die folgenden Konstanten bekannt:
| Konstante | Wert | Beschreibung |
|---|---|---|
| UPLOAD_ERR_OK | 0 | Sehr beliebt, denn es liegt kein Fehler vor. |
| UPLOAD_ERR_INI_SIZE | 1 | Die hochgeladene Datei ist größer, als es die Einstellung in der php.ini erlaubt. |
| UPLOAD_ERR_FORM_SIZE | 2 | Die Datei ist größer als das in dem HTML-Formular mittels der Anweisung MAX_FILE_SIZE angegebene Limit. |
| UPLOAD_ERR_PARTIAL | 3 | Die Datei wurde nicht vollständig hochgeladen. |
| UPLOAD_ERR_NO_FILE | 4 | Es wurde keine Datei hochgeladen. |
Nun ist die deutsche Dokumentation an dieser Stelle nicht besonders gut gepflegt. Den in der englischen stehen noch weitere Konstanten, die ich hier niemanden vorenthalten will.
| Konstante | Wert | Beschreibung |
|---|---|---|
| UPLOAD_ERR_NO_TMP_DIR | 6 | Es wird ein temporäres Verzeichnis vermisst, in das die Datei unmittelbar nach dem Upload abgelegt werden könnte (Index tmp_name in $_FILES). Seit PHP 4.3.10 und PHP 5.0.3 vorhanden. |
| UPLOAD_ERR_CANT_WRITE | 7 | Die Datei konnte nicht auf die Festplatte des Servers geschrieben werden. Seit PHP 5.1.0 vorhanden. |
| UPLOAD_ERR_EXTENSION | 8 | Der Upload wurde von einer PHP-Extension gestoppt. Welche erfährt man allerdings nicht. Seit PHP 5.2.0 vorhanden. |
Und die Antwort kommt in Form einer kleinen Funktion. is_serialized() versucht einen String zu deserialisieren und gibt true bzw. false zurück. Um die notices, die unserialize() im Fehlerfall gibt, zu verhindern, wird das Error-Reporting deaktiviert und anschließend wieder auf die Ursprungseinstellung zurück gesetzt.
function is_serialized($mSample) {
if (!is_string($mSample)) {
return false;
}
$iErrorReporting = error_reporting();
error_reporting(0);
$mTemp = unserialize($mSample);
error_reporting($iErrorReporting);
return (false === $mTemp ? false : true);
}