Damit wir zum Testen ein paar “lebendige” Daten haben, schreiben wir uns erstmal eine kleine Testklasse.

<?php
// myDate.php
class myDate
{
  function date($format='Y-m-d H:i:s', $timestamp = null)
  {
    return date($format, ($timestamp ? $timestamp : time()));
  }
}

Im Prinzip kann hier eine beliebige Klasse verwendet werden.

Da wir nun eine Datenquelle haben, müssen wir diese auch zugänglich machen. Der Webservice dient aber nicht nur dem Datenaustausch. Objekte und Funktionen können damit über das Netzwerk fernbedient werden. Im besten Fall merkt man den Unterschied nicht, ob man mit einem lokalen Objekt oder einem Webservice arbeitet.

Nun aber zu unserem Server…

<?php
// server.php
require_once('myDate.php');

$server = new SoapServer(null, array('uri' => 'http://test-webservice/'));
$server->setClass('myDate');  // oder $server->setObject(new myDate());
$server->handle();

Zuerst binden wir die Klasse myDate ein. Innerhald einer Anwendung wird das wahrscheinlich über Autoload geschehen. Die Instanz des Servers erzeuge ich in minimalster Form, ebenso sparsam bin ich beim Aufruf von handle(). Damit der Server arbeiten kann, müssen wir ihm den Klassennamen oder eine fertiges Objekt übergeben.

Wer nun mehr Code beim Client erwartet, den muss ich leider enttäuschen, es wird noch weniger.

<?php
// client.php
$url = 'http://' . $_SERVER['SERVER_NAME']
     . dirname($_SERVER['PHP_SELF']) . '/server.php';
$client = new SoapClient(null, array('location' => $url,
                                     'uri' => 'http://test-webservice/'));

echo 'Output: ' . $client->date();

Wir erzeugen uns eine Instanz des Soap-Clients und können dann wie auf dem “echten” Objekt Methoden aufrufen. Die Methode Date funktionert wie die PHP-Funktion date() mit einem Standardformat.

Ein wenig mehr ist schon zu beachten, wenn wir den Server in einer Controller-Action verbauen wollen. In dem Fall müssen wir die Ausgabe buffern und ans das Response-Objekt übergeben.

$server = new SoapServer(null, array('uri' => 'http://test-webservice/'));
$server->setObject($helper);

ob_start();
$server->handle(file_get_contents('php://input'));
$this->getResponse()->appendBody(ob_get_contents());
ob_clean();

Wer mehr zu dem Thema wissen will, sollte sich das Kapitel SOAP im PHP-Manual ansehen.

Und schon wieder die Frage, was kann unsere Klasse dann mehr? Oder warum machen wir das?

Oftmals haben wir Objekte, die eine gewisse Menge identischer Methoden benötigen, jedoch nicht aus einer Vererbungslinie stammen.

Durch die Plugins können wir dann quasi Funktionen an unsere Objekte dran kleben und nutzen. Diesen Code müssen wir nur einmal schreiben, haben auch nur eine Stelle im Code zu pflegen und können dadurch sicherstellen, dass alles gleich funktioniert.

So erweitern wir nun also zuerst wie gewohnt unser Custom_Model um ein paar neue Methoden und Eigenschaften.

<?php
class Custom_Model implements Custom_Model_Interface
{
  // ...
  protected $_plugins;

  public function registerPlugin() {}
  public function unregisterPlugin() {}
  // ...
}

Und das Interface für die Plugins.

<?php
interface Custom_Model_Plugin_Interface {}

Beim Speichern der Plugins kommt wieder die Klasse SplObjectStorage zum Einsatz, welche wir ja schon bei der Implementierung des Obeservers verwendet haben. Demnach ist es auch nicht überraschend, dass die Registrierung an die Abmeldung der Plugins sehr einfach wird.

public function registerPlugin(Custom_Model_Plugin_Interface $plugin)
{
  $this->_plugins->attach($plugin);
  return $this;
}

public function unregisterPlugin(Custom_Model_Plugin_Interface $plugin)
{
  $this->_plugins->detach($plugin);
  return $this;
}

Die Models müssen das Interface Custom_Model_Plugin_Interface implementieren. Dieses Interface ist lediglich ein Flag- oder Marker-Interface, d.h. es schreibt keine Methoden vor.

Jetzt noch eine kleine Änderung an der Methode __call() und wir können schon mit dem Beispiel experimentieren.

public function __call($method, $args)
{
  // Magie für die Getter & Setter

  foreach($this->_plugins as $plugin) {
    if(method_exists($plugin, $method)) {
      array_unshift($args, $this);
      return call_user_func_array(array($plugin, $method), $args);
    }
  }

  // Fehlerbehandlung
}

Durch __call() können wir unsere Plugin-Methoden so nutzen, als gehörten sie direkt zum Objekt. Die Art wie die Plugins verwendet werden  hat Vor-, aber auch Nachteile.

Die Liste der Plugins wird der Reihe nach durchlaufen und die erstbeste passende Methode wird aufgerufen. Auch die Getter oder Setter könnten wir nicht mehr überschreiben. Wenn das alles jedoch gewollt ist, dann lässt sich das aber auch mit wenigen Handgriffen erweitern.

Nun aber mal was praktisches zum Anschauen: Angenommen wir haben eine Model-Klasse mit Abhängigkeit zu anderen Objekten.

<?php
class Book extends Custom_Model
{
  protected $_id;
  protected $_title;
  protected $_ownerId;
}

Nun wollen wir nicht nur die ID des Besitzers erfahren, sondern auch das Objekt das bekommen können. Dafür spendieren wir ein Plugin.

<?php
class GetOwnerPlugin implements Custom_Model_Plugin_Interface
{
  public function getOwner($sender)
  {
    $id = $sender->getOwnerId();

    // lade User-Objekt $owner anhand der $id

    return $owner;
  }
}

Auf die Fehlerbehandlung habe ich an der Stelle mal verzichtet, sollte jedoch unbedingt stattfinden.

<?php
$book = new Book();
$book->registerPlugin(new GetOwnerPlugin());
$book->setOwnerId(42);
$owner = $book->getOwner();

Spätestens hier fällt sicher nicht nur mir auf, dass das Konzept noch Lücken hat. Theoretisch kann es sein, dass zu verschiedenen IDs ein User-Objekt nachgeladen werden soll (getAuthor(), getModifier(), getLastVisitor()…) und dann bräuchten wir sämtliche Methoden in unserem Plugin oder verschiedene Plugins.

Dann hätten wir aber auch wieder mehrfachen Code und nichts gewonnen. Daher werde ich die Pluginschnittstelle noch etwas aufbohren und das Ergebnis dann in einem meiner nächsten Artikel vorstellen.

Zuerst erweitern wir das Interface Custom_Model_Interface um SplSubject und ein paar eigene Methoden.

<?php
interface Custom_Model_Interface
    extends ArrayAccess,
            Iterator,
            Countable,
            SplSubject
{
  public function mark();
  public function modified();
  public function cleanModified();
  public function modifiedKeys();
}

Anschliessend kümmern wir uns um die Klassen Custom_Model und bauen alles Nötige ein.

<?php
class Custom_Model implements Custom_Model_Interface
{
  // ...
  protected $_observers;
  protected $_modified;

  public function attach(SplObserver $observer) {}
  public function detach(SplObserver $observer) {}
  public function notify() {}

  public function mark() {}
  public function modified() {}
  public function cleanModified() {}
  public function modifiedKeys() {}
  // ...
}

So weit, so gut! Die ersten drei Methoden attach(), detach() und notify() werden durch das Interface SplSubject vorgeschrieben und sind die Schnittstelle, um Observer am Objekt zu registrieren, sie zu entfernen oder zu benachrichtigen.

Mit den vier weiteren können wir den Status des Objektes setzen oder kontrollieren. Die beiden protected Eigenschaften enthalten eine Liste von Typ SplObjectStorage für die Observer und ein einfaches Array für den jeweiligen Status eines Feldes.

Bevor wir das verwenden können, müssen wir es im Konstruktor initialisieren.

public final function __construct()
{
  $this->_observers = new SplObjectStorage();
  $this->cleanModified();
  // ...
}

Der Vorteil von SplObjectStorage ist der, dass jedes Objekt nur einmal darin vorkommen kann und wir uns um die Steuerung keine Gedanken machen müssen. Das macht dann auch das Hinzufügen und Entfernen eines Observers sehr einfach.

public function attach(SplObserver $observer)
{
  $this->_observers->attach($observer);
  return $this;
}

public function detach(SplObserver $observer)
{
  $this->_observers->detach($observer);
  return $this;
}

Mir zaubert das immer ein breites Grinsen ins Gesicht, wenn eine Aufgabe mit so wenig Code gelöst werden kann und der Doc-Block teilweise länger ist als die Funktion.

Aber nun wieder zum Thema. Bevor wir uns an die wirklich einfache Benachrichtigung machen, werde ich noch schnell auf die Sache mit der Statuskontrolle eingehen. Eine Aktion, z.B. _set() setzt den “modified”-Status eines Feldes, so dass jeder Schreibzugriff auf das Modell erkennbar wird.

Dadurch haben wir später die Möglichkeit, nur zu benachrichtigen, wenn es nötig ist oder auch nur die Felder zu speichern, die sich verändert haben.

Um eine Änderung bekannt zu machen verwenden wir mark().

public function mark($key)
{
  if($this->keyExists($key)) {
    $this->_modified[$this->_mapKey($key)] = true;
  }
  return $this;
}

Die Methode erwartet den Namen eines existierenden Feldes und setzt ein Flag im Array.

Um den Status des Objektes oder eines einzelnen Feldes abfragen zu können haben wir dann modified().

public function modified($key = null)
{
  if(null !== $key) {
    return isset($this->_modified[$this->_mapKey($key)]);
  }
  return count($this->_modified) > 0;
}

Durch die Angabe des Parameters $key wird ein Feld abgefragt, ansonsten der Gesamtstatus. Nach dem selben Prinzip funktioniert dann auch cleanModified(), um den Status wieder zurück zu setzen.

public function cleanModified($key = null)
{
  if(null != $key) {
    unset($this->_modified[$this->_mapKey($key)]);
  } else {
    $this->_modified = array();
  }
  return $this;
}

Falls wir eine Liste der veränderten Felder brauchen, dann ist dafür modifiedKeys() vorgesehen.

public function modifiedKeys()
{
  $keys = array();

  foreach($this->_keys as $key) {
    if($this->modified($key)) {
      $keys[] = $key;
    }
  }

  return $keys;
}

Nachdem wir das alles durch haben, können wir uns nun notify() widmen, bevor wir unser Werk an ein paar Beispielen testen können.

public function notify()
{
  if($this->modified()) {
    foreach($this->_observers as $observer) {
      $observer->update($this);
    }
  }
  $this->cleanModified();
  return $this;
}

Die Methode macht im Prinzip nichts weiter, als bei allen in der Liste befindlichen Observer-Objekten update() aufzurufen und sich selbst als Parameter mitzugeben. Dadurch weiß die Observerklasse gleich, welches Objekt sich verändert hat.

Das folgende Beispiel zeigt einen einfachen Beobachter, der nur den Klassennamen von $subject ausgibt und eine Liste der geänderten Felder, wenn das Objekt vom Typ Custom_Model ist.

class myObserver implements SplObserver
{
  public function update(SplSubject $subject)
  {
    echo get_class($subject) . ' hat sich verändert<br/>';
    if($subject instanceof Custom_Model) {
      print_r($subject->modifiedKeys());
    }
  }
}

$model = new Person();
$model->attach(new myObserver());
$model->setId(42)
      ->setVorname('Bart');

$model->notify();

Das interessante an dem Observer-Muster ist die lose Kopplung der Objekte und die Tatsache, dass ein Observer beliebig viele Subjekte beobachten kann und umgekehrt ein Subjekt beliebig viele Observer haben kann.

So, das war es dann auch schon für diese Woche und zu diesem Thema. Wie ich einst schon sagte, ist es ein sehr ergiebiges Thema, weil sich viele Techniken in sinnvoller Verbindung anwenden lassen. Bislang haben wir trotzdem erst nur einen Datenklumpen mit etwas Dekoration.

Richtig interessant wird es dann, wenn wir die Models über Mapper-Klassen laden und speichern können, aber das wird dann evtl. das Thema einer neuen Serie…

Was kann unser Model dann, was es vorher noch nicht konnte? Durch die Verwendung des Interfaces können wir die gespeicherten Daten in einer foreach-Schleife verarbeiten. Das kann z.B. beim erzeugen von Tabellen erforderlich sein.

Wie immer beginne ich mit einer Skizze der heutigen Erweiterungen.

<?php
interface Custom_Model_Interface
  extends ArrayAccess,
          Iterator,
          Countable
{
}

Unser Interface Custom_Model_Interface erweitert zunächst das Iterator-Interface und auch Countable. Dadurch lassen sich dann die Elemente des Objektes zählen und in Verbindung mit ArrayAccess auch beliebig in einer for-Schleife verarbeiten.

In unserer Klasse müssen wir nun die entsprechenden Methoden deklarieren.

<?php
class Custom_Model implements Custom_Model_Interface
{
  // ...

  public function current() {}
  public function key() {}
  public function next() {}
  public function rewind() {}
  public function valid() {}
  public function count() {}

// ...
}

Jedem, der lange genug mit PHP arbeitet sollte nun was auffallen. Richtig! Wir halten unsere “Feldnamen” in einem Array und zu fast jeder Methode gibt es eine gleichnamige Array-Funktion.

Da wir aber an meistens an die Werte und nicht an die Namen der Felder wollen, müssen wir etwas tricksen.

Die erste Methode current() gibt das jeweilige Element an der Position des internen Zeigers zurück und entspricht damit der gleichnamigen Array-Funktion current().

public function current()
{
  return $this->_get(current($this->_keys));
}

Das Gegenstück dazu stellt quasi key() dar, da es den Feldnamen der Position liefert.

public function key()
{
  return $this->_keys[key($this->_keys)];
}

Auf den ersten Blick mag diese Schreibweise vielleicht etwas verwirren, aber nur so bekommen wir den richtigen Schlüssel. key() gibt uns den aktuellen Schlüssel von $this->_keys zurück, wir wollen den Wert der jeweiligen Position haben.

Um nun in der Schleife den internen Zeiger bewegen zu können, brauchen wir next().

public function next()
{
  next($this->_keys);
}

Wird das Objekt ein weiteres Mal mit foreach verarbeitet, so muss der interne Zeiger wieder auf die erste Position zurückgesetzt werden. Das Iterator-Interface schreibt dafür die Methode rewind() vor, die dann intern reset() verwenden kann.

public function rewind()
{
  reset($this->_keys);
}

Innerhalb der Schleife wir überprüft, ob weitere Elemente vorhanden sind. Dazu wird valid() verwendet.

public function valid()
{
  return current($this->_keys) !== false;
}

Damit haben wir alles notwendige eingebaut, damit unser Model in einer foreach-Schleife ausgelesen werden kann.

foreach($model as $key=>$value) {
  echo $key . ' = ' . $value . '<br/>';
}

Zuletzt gibt es dann auch noch die Methode count() des Countable-Interfaces, damit wir beliebig mit for-Schleifen über das Objekt iterieren können.

public function count()
{
  return count($this->_keys);    
}

und

for($i=0; $i<count($model); $i++) {
  echo $i . ' = ' . $model[$i] . '<br/>';
}

Damit wären wir auch schon wieder am Ende. Beim nächsten Mal geht es dann weiter mit dem Observer-Pattern.

Angenommen, über ein Formular sollen die Stammdaten von Kunden bearbeitet werden und wir wollen dem Bearbeiter das Leben etwas leichter machen, indem er nach dem Speichern der Daten direkt die nächste Aktion ausführen kann ohne sie in der Navigation zu suchen.

In unserem Fall könnten die Aktionen z.B. ‘speichern’, ‘speichern und zur Liste’ und ‘speichern und neu anlegen’ sein.

Erstmal brauchen wir ein gewöhnliches Affenformular mit den gewünschten Eingabefeldern:

<form action="machwas" method="post">
  // ein paar Felder
  <input type="submit" value="speichern">
</form>

Soweit, so gut. Bislang ein ganz gewöhnliches Formular. Doch wie steuern wir denn nun was nach dem Absenden passieren soll? Ganz einfach, wir geben dem Formular noch ein paar Buttons und benennen diese.

<form action="machwas" method="post">
  // ein paar Felder
  <input type="submit" value="speichern" name="btnSave">
  <input type="submit" value="speichern und zur Liste" name="btnSaveList">
  <input type="submit" value="speichern und neu anlegen" name="btnSaveNew">
</form>

Für diesen Zweck habe ich mir angewöhnt, den Namen das Prefix ‘btn’ zu geben, damit sie besser zuordenbar sind.

Was passiert nun? Durch die Benennung der Buttons wird deren Wert (value) mit den andere Werten übertragen und wir können serverseitig damit arbeiten.

Theoretisch hätte ich auch alle Buttons gleich benennen können und hätte dann mit dem jeweiligen Wert weiter arbeiten können, aber dieser wäre nicht zuverlässig nutzbar. Dazu etwas später mehr.

Natürlich brauchen wir auch noch eine Auswertung für unser Formular:

<?php
// Daten prüfen, speichern und weiterleiten, wenn alles geklappt hat...

if(isset($_REQUEST['btnSave'])) {
  // ...und wieder auf das Formular weiterleiten (mit Daten anzeigen)
} else if(isset($_REQUEST['btnSaveList'])) {
  // ...und zur Liste weiterleiten
} else if(isset($_REQUEST['btnSaveNew'])) {
  // ...und wieder auf das Formular weiterleiten (ohne Daten anzeigen)
}

Das Beispiel funktioniert auch mit anderen Sprachen, müsste dann aber natürlich an die Syntax angepasst werden. Persönlich finde ich nach einem POST-Request einen HTTP-Redirect ganz nützlich.

Nun noch kurz die Aufklärung, warum ich die Namen der Buttons auswerte. Es ist einfacher, da der Name sich in der Regel nicht verändert, jedoch evtl. die Beschriftung und somit der Wert, wenn die Anwendung mehrsprachig programmiert ist.

Ich hoffe, dass es vielleicht dem Einen oder Anderen hilft, auch wenn es eigentlich zu den Basics gehört. Viel Spaß beim Ausprobieren!

Zunächst gibt es verschiedene Arten Vorschaubilder zu erzeugen. Die sicherlich primitivste ist das gegebene Bild auf die gewünschte Größe zu kopieren, denn die meisten Bilder sind original nicht quadratisch und würden dann verzerrt werden. Daher müssen wir die neuen Werte vorher berechnen, um gute Ergebnisse zu bekommen.

Gehen wir nun einfach mal davon aus, dass unsere Vorschaubilder eine maximale Seitenlänge haben und quadratisch sein sollen. Jetzt können wir entweder das Bild komplett kopieren und den Rest ggf. mit einer beliebigen Farbe auffüllen, oder wir kopieren einen Ausschnitt und haben dann ein vollflächiges Vorschaubild.

Für die proportionale Anpassung an unsere maximale Seitenlänge müssen wir zuerst das Bildformat, bzw. die Ausrichtung des Originalbildes ermitteln.

if (srcHeight < srcWidth) {
  // Querformat
} else {
  // Hochformat
}

Danach errechnen wir die neuen Maße des Bildes. Bei der ersten Variante setzen wir unseren Maximalwert der längeren Bildseite gleich und passen die andere Seite an. Dadurch vermeiden wir, dass das Bild evtl. vergrößert würde, falls das Original kleiner als unser gewünschtes Vorschaubild ist.

if (srcHeight < srcWidth) {
  destWidth  = maxsize / srcHeight * srcWidth;
  destHeight = maxsize = maxsize <= srcHeight ? maxsize : srcHeight;
} else {
  destWidth  = maxsize <= srcWidth ? maxsize : srcWidth;
  destHeight = maxsize / srcWidth * srcHeight;
}

Die Variablen srcWidth und srcHeight sollten die Werte des Originalbildes haben und destWidth und destHeight bekommen die Werte für das neue, kleinere Bild. Mit diesen Werten kann nun das Vorschaubild erzeugt werden.

Wenn das neue Bild nicht nur kleiner, sondern auch quadratisch und mit einer Hintergrundfarbe gefüllt sein soll, dann muss dazu ein Bild mit den gewünschten Maßen (maximale Seitenlänge im Quadrat) erzeugt und mit der Wunschfarbe gefüllt werden. Anschliessend das Originalbild verkleinert und zentriert daraufkopieren.

Die zweite Variante, nur einen Ausschnitt zu kopieren, funktioniert etwas anders, da wir dazu den jeweiligen Offset, also den Versatz vom Bildrand, errechnen müssen.

offsetX = 0;
offsetY = 0;

if (srcHeight < srcWidth) {
  offsetX = round ( (srcWidth / 2) - (srcHeight / 2) );
} else {
  offsetY = round ( (srcHeight / 2) - (srcWidth / 2) );
}

Mit diesen Werten kann nun ein Quadrat mit dem entsprechenden Abstand aus dem Originalbild verkleinert kopiert werden und das war es auch schon.

Wie die Bilder im einzelnen bearbeitet werden und welche Klassen oder Funktionen verwendet werden können oder sollten, hängt dann von der jeweiligen Programmiersprache und den verwendeten Bibliotheken ab, daher gehe ich darauf an dieser Stelle auch nicht weiter ein.

Trotz zunehmender Rechenleistung empfehle ich, die erzeugten Vorschaubilder für die weitere Verwendung zu speichern und nicht jedesmal neu zu generieren.

Siehe auch:

• Bildbearbeitung mit PHP