Als ich mich vor ein paar Jahren auf meine Java-Zertifizierung vorbereitet habe, ist mir ein Satz immer wieder begegnet: “Programm to an interface, not to an implementation!”. Klingt einfach, ist es auch.

Im Prinzip sagt das nur aus, dass man sich beim Entwickeln nur darauf verlassen sollte, was die jeweilig implementierten Interfaces an Funktionalität anbieten. Wie das ganze dann im Hintergrund implementiert ist, interessiert dann nicht mehr.

Ein kleines Beispiel aus der Praxis: In einem Shop (in dem Fall Magento) werden Bestellungen (Orders) gespeichert. Nun soll ein ERP-System angebunden werden. Für beide Systeme gibt es entsprechende Models, mit denen die Daten verarbeitet werden können.

Soweit, so gut. Jetzt kommt der unbequeme Teil der Aufgabe. Das Magento-Order-Model erbt einfach nur von verschiedenen anderen Klassen, aber es existiert kein Interface, das dem Entwickler bestimmte Methoden garantiert. An vielen Stellen werden zudem die Parameter mit Type-Hinting überprüft, ob sie eine Magento-Order enthalten.

Das Model für die Anbindung an das ERP-System hat unter Umständen andere Elternklassen und somit auch erstmal keine Gemeinsamkeiten. Das bedeutet, dass wir theoretisch die Objekte gleich behandeln könnten, aber wir sie für das Type-Hinting doch wieder in Wrapper verpacken oder auf Magento-Order-Objekte mappen müssen.

Diese Arbeit könnte man sich komplett sparen, wenn man sich von Anfang an auf ein Interface verlassen hätte. Leider existiert dieses meines Wissens nicht und es für eigene Projekte zu nutzen würde Änderungen in den Magento-Core-Dateien fordern.

<?php
interface Mage_Sales_Model_Order_Interface
{
  /**
   * Retrieve customer model
   *
   * @return Mage_Customer_Model_Customer_Interface
   */
  public function getCustomer();

  // ...
}

Damit könnte man sich auf verschiedene Methoden verlassen die der Typ Mage_Sales_Model_Order_Interface (!) zusagt.

<?php
class Mage_Sales_Model_Order
  extends Mage_Sales_Model_Abstract
  implements Mage_Sales_Model_Order_Interface
{
  // ...
}

Die Klasse Mage_Sales_Model_Order könnte sich an diesen “Vertrag” halten,

<?php
class Erp_Sales_Model_Order
  extends Erp_Was_Auch_Immer_Model_Abstract
  implements Mage_Sales_Model_Order_Interface
{
  // ...
}

sowie auch jede andere Klasse.

<?php
// ...
public function getEmailFromOrder(Mage_Sales_Model_Order_Interface $order)
{
  return $order->getCustomer()->getEmail();
}
// ...

So können wir jede beliebige Klasse mit bestehenden Code weiterhin verarbeiten, ohne dass uns das Type-Hinting dabei im Weg steht. Was die Methode getCustomer() nun intern macht, ist uns egal, solange ein Objekt vom Typ Mage_Customer_Model_Customer_Interface zurückgegeben wird.

Es ist vielleicht auf den ersten Blick etwas umständlicher, für jeden Typ ein Interface zu schreiben, aber das spart man danach wieder locker ein und bleibt dazu auch in der weiteren Entwicklung seiner Anwendung flexibel.

Gleichzeitig wollen wir aber zu jeder Zeit sicherstellen, dass wir das Model wie gewohnt vollständig abfragen und verwenden können. An dieser Stelle kommt eine Technik namens LazyLoading (lazy = engl. faul, träge) zum Einsatz.

Nun konstruiere ich einfach ein Beispiel, um den Ablauf besser erklären zu können. In unserer Anwendung brauchen wir ein Model “Person”, das Informationen wie Name, Geburtstag und diverse andere speichern kann. Den Namen und den Geburtstag brauchen wir immer (z.B. in der Listenansicht) und die restlichen Felder nur wenn wir eine Detailansicht erstellen.

Wie kommt unser Model nun an die Daten? In der Regel wird sicherlich load() auf dem Modelobjekt aufgerufen oder eine vergleichbare Methode auf der jeweiligen Collection, dann werden die Daten über ein Resourcemodel geladen und letztendlich komplett auf die einzelnen Modelobjekte kopiert.

Um unser Vorhaben umzusetzen müssen wir das etwas abändern. Die Methode load() des Models funktioniert wie gewohnt und lädt alle Daten und die Collection nur die Nötigsten. Um nun sicherzustellen, dass wir trotzdem immer alles abrufen können, muss das Model etwas intelligenter werden.

Die Entwicklung des Custom_Models hat der eine oder andere ja vielleicht mitbekommen und kennt den grundlegenden Aufbau. Relativ neu ist die Klasse Custom_Model_Persistent, durch die eine weitere Unterscheidung zwischen einfachen Datencontainern und speicherbaren Models möglich wird.

Für das automatische Nachladen muss die Modelklasse nun erweitert werden.

<?php
class Custom_Model_Persistent extends Custom_Model
{
  private $_isLoaded;

  // ...

  public function load($value = null, $field = 'id')
  {
    if (null === $value && $this->_isset($field)) {
      $value = $this->_get($field);
    }

    $this->getResource()
         ->loadModel($this, $value, $this->_mapKey($field))
         ->markLoaded();

    return $this;
  }

  public function isLoaded()
  {
    return $this->_isLoaded;
  }

  public function markLoaded()
  {
    $this->_isLoaded = true;
    return $this;
  }

  protected function _get($key, $default = null)
  {
    if (!$this->_isset($key) && !$this->isLoaded()) {
      $this->load();
    }
    return parent::_get($key, $default);
  }
}

Die entscheidenen Stellen sind hier der überschriebene zentrale Getter, der ein das “Default-Load()” auslöst, wenn der Wert nicht gesetzt ist und die Daten auch noch nicht vollständig geladen wurden und die Methode load() mit optionalen Parameter $value.

Im Beispiel verlasse ich mich darauf, dass das Standardfeld schon gesetzt ist. Eine ordentliche Fehlerbehandlung muss aber unbedingt her, wenn wir das ganze produktiv einsetzen wollen.

Die Methoden isLoaded() bzw markLoaded() sind absichtlich public, damit sie z.B. aus einer Collection aufgerufen werden können, wenn das Model komplett geladen wurde. Eine weitere Möglichkeit wäre ein Vergleich mit einer Liste die gesetzt sein sollten.

Im Moment ist das noch etwas im Entwurf und sogar ungetestet. Wenn euch nun noch was dazu einfällt, dann schreibt einen Kommentar. Wo seht ihr für euch die Vor- oder evtl. auch die Nachteile?

Es gibt aber auch Fälle, in denen die magische Methode __call() den Code lesbarer machen kann und gleichzeitig eine Menge Schreibarbeit einspart.

Stellen wir uns einfach mal vor, wir hätten ein Model mit 20 Werten und wollen es anhand eines bestimmten Feldes laden.

<?php
$model->load($id);  // lädt das Model mit Defaultkey = $id, oder

$model->load('Daniel', 'name');  // Feld 'name' = 'Daniel'

Letzteres ist durchaus gut zu lesen und lädt bestenfalls auch die richtigen Daten. Mit __call() lässt sich das ganze ohne viel Aufwand noch etwas dekorieren, so dass wir das Model dann so laden können:

<?php
$model->loadByName('Daniel');

Nun könnte man entweder für alle 20 Felder die jeweiligen Methoden schreiben, oder eine Art Template mit __call() und eines RegEx erstellen und den Aufruf einfach deligieren.

<?php
class Custom_Model
{
  public function __call($method, $args)
  {
    if (preg_match('/^loadBy([a-zA-Z]*?)$/', $method, $matches))
      return $this->load($args[0], $matches[1]);
    }
    // ...
  }
}

Der Vorteil ist ganz klar die eingesparte Tipparbeit und eine übersichtlichere Klasse, da wir alleine für diese Funktionalität 20 Methoden weniger im Code haben. Jedoch ist auch der Nachteil nicht außer Acht zu lassen. Weil die Methoden nur virtuell existieren, sind sie z.B. für die IDE unsichtbar und sind daher auch für neue Entwickler nicht sofort erkennbar.

Es bleibt also wieder dem eigenen Geschmack überlassen, für welchen Weg man sich entscheidet.

Die Underscore-Schreibart (z.B. “user_id”) findet man sehr oft als Spaltenbezeichner in Datenbanken oder auch in XML-Dateien, im PHP-Model (siehe auch mein Artikel zum Custom_Model) hingegen wird oft CamelCase (z.B. “userId”) verwendet.

Es wird also an der Schnittstelle zwischen dem Model und der Datenquelle eine Art Key-Mapping benötigt. Das lässt sich zwar recht einfach mit regulären Ausdrücken erschlagen, aber man kann sich auch der Zend_Filter-Klassen bedienen, wenn man in einem ZF-Umfeld arbeitet.

Die Anwendung ist wie so vieles beim Zend Framework recht einfach:

<?php
$toCamelCaseFilter = new Zend_Filter_Word_UnderscoreToCamelCase();
echo $toCamelCaseFilter->filter('user_id');

// Ausgabe: UserId

Umgekehrt, wen wird es wundern, ist das natürlich genauso leicht:

<?php
$toUnderscoreFilter = new Zend_Filter_Word_CamelCaseToUnderscore();
echo $toUnderscoreFilter->filter('UserId');

// Ausgabe: User_Id

Wenn man nicht extra eine Instanz erzeugen will, dann lassen sich die Zend Filter auch mit einem statischen Aufruf nutzen.

<?php
echo Zend_Filter::filterStatic('bitte_einmal_camel_case',
                               'Word_UnderscoreToCamelCase');

// Ausgabe: BitteEinmalCamelCase

Das war es dann auch schon wieder für heute. Ich hoffe, dass euch der Artikel gefallen hat und ihr viele kreative Ideen zum Arbeiten mit den Filtern habt.

Diverse Werte

<?php $storeId = Mage::app()->getStore()->getId(); $storeName = Mage::app()->getStore()->getName(); $storeCode = Mage::app()->getStore()->getCode(); $groupId = Mage::app()->getStore()->getGroupID(); $groupName = Mage::app()->getStore()->getGroup()->getName(); $websiteName = Mage::app()->getWebsite()->getName();

Session

<?php
$sessionId  = Mage::getModel('core/session')->getSessionId();
$customerId = Mage::getModel('customer/session')->getCustomerId();
$vistitorId = Mage::getModel('core/session')->getVisitorId();

Models

<?php $customer = Mage::getModel('customer/customer'); $order = Mage::getModel('sales/order'); $product = Mage::getModel('catalog/product'); 

Produkt-Model

$product    = Mage::getModel('catalog/product')->load($productId);
$categories = $product->getCategoryCollection();

Konfiguration

auslesen

$value = Mage::getStoreConfig('[MODULE]/[SECTION]/[FIELD]', $storeId);

und wieder schreiben

// Wert für Store 1 setzen
Mage::getConfig()->saveConfig('path/to/config/value', 12343, 'stores', 1);

// oder als Defaultwert
Mage::getConfig()->saveConfig('path/to/config/value', 12343);

Blocks

<?php $block = Mage::app()->getLayout()->createBlock('log/...');

Helpers

<?php
$helper = Mage::helper('helper');

Logging

<?php Mage::log('Schreibe das ins Logfile');

Sonstiges

Store-Umgebung simulieren

Mage::app()->getLocale()->emulate($storeId);

Events auslösen

Mage::dispatchEvent($eventName);

Es geht weiter…

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…