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?

Viele Fehler treten bei Magento schon durch eine fehlerhafte Konfiguration auf, was zur Folge haben kann, dass wir keine Instanz unser lokalisierten Klasse bekommen, sondern ein standard Magento-Objekt oder einen Fehler, weil keine passende Klasse gefunden wird.

So habe ich also angefangen, die Existenz der zu prüfenden Klassen zu testen und ob die Mage-Factory das gewünschte Objekt zurück gibt. Bei einigen Klassen ist es zudem auch noch wichtig, dass sie von der richtigen Elternklasse abgeleitet sind.

Da sich diese Tests immer wiederholten, zeichnete sich schnell ein Muster ab. Ebenso erfolgt auch die Namesgebung der Magentoklassen nach einem gewissen Muster. Was wäre also naheliegender, als beides miteinander zu verbinden und so in Zukunft eine Menge unnützer Schreibarbeit zu sparen?

Als erstes habe ich dafür einen erweiteren TestCase vom PHPUnit-TestCase abgeleitet, der mir weitere vereinfachte Asserts zur Verfügung stellt und die Tests dadurch auch etwas lesbarer macht.

$this->assertClassExists($classname);

statt

$this->assertTrue(class_exists($classname));

Auf diesem Wege lassen sich dann auch z.B. Getter und Setter einfach auf das gewünschte Standardverhalten prüfen.

Im nächsten Schritt habe ich einen Entity-TestCase abgeleitet, der als Basis für alle weiteren TestCases für Models, Blocks und Helper dienen soll. Dieser ist in sich schon ein wenig intelligenter und erkennt anhand des Namens der Test-Klasse, welche Klasse getestet werden soll, welchen Typ diese hat und welche die Standard-Elternklasse ist.

Diese Informationen werden, nebenbei bemerkt, durch protected Methoden ermittelt und könnten zu jeder Zeit durch noch speziellere TestCases wieder überschrieben werden.

Mit den nun vorliegenden Informationen ist diese TestCase-Klasse mächtig genug, um alleine durch Vererbung die grundlegenden Tests durchzuführen.

Für die jeweiligen Typen, z.B. Model habe ich dann noch weitere TestCases abgeleitet, um dort noch spezielle Methoden implementieren zu können.

Ein sehr einfacher Test für die Model-Klasse “Mein_Customer_Model_Customer” sähe dann beispielsweise so aus:

class Mein_Customer_Model_CustomerTest extends Mein_Model_TestCase
{
}

Dadurch würde nun automatisch getestet werden, ob der Autoloader die Klasse “Mein_Customer_Model_Customer” finden kann, diese von der Magento-Model-Klasse erbt und ob die Factory aufgrund der Konfiguration auch das richtige Objekt liefert.

Ich denke, dass es viel einfacher nicht mehr geht und das Argument gegen Tests damit dann auch aus der Welt sein sollte.

Kleiner Tipp: Wenn man es nun noch etwas konfortabler mag, dann kann man sich seine Models auch mit dem Zend_CodeGenerator bauen lassen und die Tests gleich mit.

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…

Die Lösung ist deratig einfach, wenn man es weiß… Die Einstellung für das jeweilige Event muss natürlich im richtigen Scope in der config.xml gemacht werden.

Ist der Beobachter nun also global eingestellt, klappt es auch in allen Bereichen. Andersherum lässt sich so aber auch eine unterschiedliche Verarbeitung für das selbe Ereignis einstellen.

Viele Methoden sind mit __call() implementiert und das hat die Nachteile, dass z.B. die Codecompletion, Reflection, automatische Dokumentation oder die Navigation in der IDE ausgehebelt werden.

Zum Glück können wir das ja zum Teil in vererbten Klassen wieder abfangen, ohne die ursprünglichen Klassen umschreiben zu müssen, z.B. weil wir die fremden Libraries zwecks späterer Updates nicht verändern wollen.

<?php

class A
{
  public function __call($method, $args)
  {
    echo __METHOD__ . ' ' . $method;
  }
}

class B extends A
{
  public function machWas()
  {
    parent::machWas();
  }
}

$b = new B();
$b->machWas();

Die Methode B::machWas() delegiert den Aufruf an die magische Methode, wobei sich das Verhalten nach außen nicht verändert, jedoch alles andere wieder funktionieren wird.