Dabei geht es um die verschiedenen Schritte, wie Daten bearbeitet werden können. CRUD ansich ist erstmal kein Designmuster im herkömmlichen Sinne, aber es lässt sich für verschiedene Arten von Datenmodellen eine immer wiederkehrendes Muster erkennen.

In vielen Projekten habe ich erlebt, dass für jedes Modell oder Entity mindestens ein Kontroller implementiert wurde, um die irgendwie manipulieren und anzeigen zu können.

Oftmals werden bekannte und gut geprüfte Frameworks eingesetzt, um die Arbeit zu erleichtern und einheitliche Standards zu nutzen.

Warum also nicht auch einfach hier fertige Module nutzen oder sollte es tatsächlich nichts fertiges geben, einfach gute eigene Basiskontroller verwenden?

Der Ausgangspunkt ist erstmal klar und einfach: CRUD, d.h. C – create (erzeugen), R – read (lesen/anzeigen), U – update (bearbeiten) und D – delete (löschen).

Damit haben wir schon unsere ersten Controller-Actions zusammen. Ich halte den Code allgemein wie möglich, da sich das auf sämtliche Frameworks übertragen lässt.

<?php
class CrudController {
  public function indexAction() {}
  public function viewAction() {}
  public function editAction() {}
  public function deleteAction() {}
}

Bei den Actions folge ich nicht ganz dem “CRUD-Muster”. Die Edit-Action vereint in diesem Beispiel “create” und “update”, da die dahinterstehende Logik oft fast identisch ist.

Kümmern wir uns doch aber erstmal um die einfachen Actions. Die index-Action soll uns eine Liste der verfügbaren Datensätze anzeigen.

Dafür laden wir eine Collection des jeweiligen Typs und rendern das passende Template. Wenn wir in der Benennung aller Klassen einer bestimmten Namenskonvention folgen, können wir z.B. vom Namen der Kontrollerklasse auf den des jeweiligen Models schließen.

class CrudController {
  public function indexAction() {
    $collection = $this->getCollection();
    return $this->render( $this->getListTemplate(), $collection );
  }
}

class UserController extend CrudController() {
}

Nach ähnlichem Muster würde dann auch die View-Action arbeiten. Den Namen des Templates leiten wir aus dem Klassennamen des Controllers ab. Das Wichtige und Interessante dabei ist natürlich, dass eigentlich alles im CrudController passiert und nicht immer wieder neu geschrieben werden soll. Die erbenden Controller geben dann nur noch ihren Namen her und passen hier und da etwas an.

class CrudController {
  public function viewAction($id) {
    $model = $this->getModel()->find($id);
    return $this->render( $this->getViewTemplate(), array('model' => $model) );
  }
}

Beim Löschen verhält es sich ähnlich einfach, nur dass hier noch ein weiterer Parameter gebraucht wird.

class CrudController {
  public function deleteAction($id, $confirm = false) {
    $model = $this->getModel()->find($id);

    if(!$confirm) {
      return $this->render( $this->getDeleteConfirmTemplate(), array('model' => $model) );
    }

    $model->delete();
    return $this->render( $this->getDeleteSuccessTemplate(), array('model' => $model) );
  }
}

Den meisten Aufwand haben wir beim Bearbeiten von Datensätzen.

class CrudController {
  public function editAction($id = false) {
    $request = $this->getRequest();
    $form = $this->getForm();

    // model bleibt leer, wenn nichts geladen werden kann
    $model = $this->getModel()->find($id);

    if($request->isPost()) {
      if($form->isValid( $request )) {
        $model->setData( $form->getData() );
        $model->save();
        $this->setFlashMsg( 'Speichern ok' );
        return $this->redirect( $this->getListUrl() );
      }
    }

    return $this->render( $this->getEditTemplate(), array('form' => $form) );
  }
}

Das Beispiel ist natürlich nicht komplett, soll aber zeigen, wieviel arbeit wir uns täglich sparen können und gleichzeitig durch einheitliche Standards ein flexibles und stabiles Produkt schaffen.

Als erstes habe ich eine eigene Eventklasse abgeleitet, die den Eventnamen speichern kann. Da dieser ja nun beim Dispatch irgendwie mitgegeben werden muss, hatte ich drei Möglichkeiten:

1. Vor dem Dispatch jedesmal den Eventnamen per Setter übergeben
2. Den Dispatcher ableiten und die Methode dispatch() überschreiben
3. Meinem Event eine eigene Dispatchmethode geben

Die erste Variante ist natürlich schon ausgeschieden, bevor die Idee ausgeschrieben war, da es zum einen unhandlich ist, unnötigen Code erzeugt und auch ein großes Fehlerpotential bildet.

Den Dispatcher zu überschreiben wäre sicher auch ein einfacher Weg gewesen, dennoch habe ich mich dann doch für die dritte Möglichkeit entschieden.

Eine eigene Klasse für das Event wurde ohnehin schon gebaut und so kann diese auch noch etwas mehr machen. Auf Typehints usw. habe ich für die Übersicht hier mal verzichtet.

<?php
namespace E7\EventDispatcher;

//use ...\EventDispatcher as ED;

class Event extends ED\Event {
  private $eventDispatcher;
  private $eventName;

  public function getEventDispatcher() {
    return $this->eventDispatcher;
  }

  public function setEventDispatcher($eventDispatcher) {
    $this->eventDispatcher = $eventDispatcher;
    return $this;
  }

  public function getEventName() {
    return $this->eventName;
  }

  public function setEventName($eventName) {
    $this->eventName = $eventName;
    return $this;
  }

  public function dispatch($eventName) {
    $this->setEventName($eventName);
    $this->getDispatcher()->dispatch($eventName, $this);
    return $this;
  }
}

Viel gewonnen haben wir so aber leider nicht. Der Aufruf passiert nun direkt auf dem Event, aber statt dem Setter für den Eventnamen müssten wir nun den Setter für den EventDispatcher aufrufen.

Meine Lösung hierfür ist eine Factory für Eventobjekte. Das ganze schafft uns bei der Verwendung weitere Vorteile.

1. Nur die Factory muss den EventDispatcher kennen und übergibt diesen an die Eventobjekte. Jede Änderung bei der Erzeugung der Events muss nun nur noch an einer Stelle gemacht werden.
2. Durch die Factory fällt der new-Operator weg und damit auch die Abhängigkeit zu speziellen Typen. Wir programmieren ab hier noch gegen das Interface

Die Factory lässt sich entweder mit einem statischem Aufruf verwenden oder man registriert sie als Service und holt sie sich über den Container. Bei Interesse kann ich auch gerne dazu noch was schreiben.

Der Umgang mit dem Symfony2 Eventhandling ist wie schon erwähnt sehr einfach und flexibel und das macht wirklich Freude damit zu arbeiten.

Aktuell habe ich es mit verschiedenen Datenmodellen zu tun, die zwar irgendwie miteinander zu tun haben, jedoch über keine direkte Verbindung verfügen. Jedes dieser Datenmodelle kann geladen, gespeichert und auch wieder gelöscht werden.

Zu jeder Aktion gehört noch ein Zeitpunkt, d.h. der oder die Listener können vorher oder nachher benachrichtigt werden und beim Speichern wollen unsere Listener vielleicht sogar wissen, ob der Datensatz neu erstellt wurde oder ob es sich nur um ein Update handelt.

Diese Anforderungen sind ansich recht übersichtlich, aber doch komplex genug, um ein wenig darüber zu schreiben.

Alle Modelle werden durch ein Resource-Modell verarbeitet und an dieser Stelle werden auch die Events ausgelöst. Es gibt für jede Aktion eine eigene EventKlasse die von einer ModelEvent-Klasse erbt und diese wiederum von Symfony-Event.

                        +-------------+
                        |    Event    |
                        +-------------+
                               |
                      +-----------------+
                      |    ModelEvent   |
                      +-----------------+
                      | get/setModel()  |
                      +-----------------+
                               |
         +---------------------+----------------------+
         |                     |                      |
+-----------------+   +-----------------+   +-------------------+
| ModelFindEvent  |   | ModelSaveEvent  |   | ModelDeleteEvent  |
+-----------------+   +-----------------+   +-------------------+
                      | - bool:isNew    |
                      | bool:isCreate() |
                      | bool:isUpdate() |
                      +-----------------+

Mein einfaches ASCI-Art UML verrät ja nun auch schon ein wenig darüber, wie die Aufgaben im System verteilt werden. Da beim Speichern das meiste passiert, sehen wir uns einfach mal die Save-Methode des Resourcen-Modells an. Die verwendeten Methoden, z.B. triggerEvent() sind in den Elternklassen definiert und nutzen den globalen Event-Dispatcher.

<?php
// ...
public function save(Model\Model $model) {
    $event = new Event\ModelSaveEvent($model);

    $this->triggerEvent('model.save.before', $event);
    $this->executeSave($model);
    $this->triggerEvent('model.save.after', $event);

    return $this;
}
// ...

Zuerst wird ein ModelSaveEvent-Object mit der Modelinstanz erzeugt und das erste Event (model.save.before) ausgelöst. Die ModelSaveEvent-Klasse erkennt nun anhand einer Methode im Model, ob dieses neu ist oder ein weiteres Mal gespeichert werden soll und merkt sich diesen anfänglichen Zustand. Dadurch kann dann auch nach dem Speichern noch festgestellt werden was passiert ist.

Danach wird eine protected Methode executeSave() aufgerufen die sich um die eigentliche Arbeit kümmert und anschliessend wird das zweite Event (model.save.after) ausgelöst.

Was haben wir dadurch nun erreicht? Wie ich im letzten Artikel schon beschrieben habe, lassen sich ja ganz einfach mehrere Events von einem Listener überwachen.

In der jeweiligen Methode könnten wir dann allgemein auf alle ModelEvents reagieren oder auch nur auf spezielle. Da wir mit dem Event auch eine Modelinstanz übergeben, können wir auch hier anhand des Types weitere Unterscheidungen machen, falls wir das müssen.

Leider geht uns bei einer Methode für alles das auslösende Event (z.B. “model.save.before”) verloren und damit auch der Zeitpunkt, wann was passiert ist.

Hier fände ich es angenehm, wenn der Symfony-Event-Dispatcher diese Information mit den Events mitgeben würde, aber man kann ja nicht alles haben und zur Not baut man es eben selbst dran.

Es geht um zwei einfache, aber zugleich sehr nützliche Dinge, die das PHP-Framework Symfony2 mitbringt: Ein einfaches, flexibles Event-Handling und Annotations.

Für mich waren die letzten drei Wochen auch die ersten Gehversuche mit Symfony2 und bislang wurden alle meine Erwartungen bestätigt. Das Framework ist sehr flexibel, aber auch recht komplex. Wer allerdings andere MVC-Frameworks wie Zend kennt, der wird sich auch hier schnell zurecht finden.

So, genug Lob an der Stelle. Neben der positiven Eigenschafft eines Eventhandlingsystems fiel mir auch gleich die Art auf, wie sich in Symfony2 Controllerrouten mit Annotations konfigurieren lassen.

Leider habe ich nichts Vergleichbares für Eventlistener gefunden und die klassische Konfiguration über YML gefiel mir dann auch nicht mehr so recht. Das nahm ich dann also gleich mal als praxisnahes Kennenlernbeispiel her und habe mir da was gebaut.

Als erstes braucht es immer einen Auslöser, damit die Annotations verarbeitet werden. Dafür habe ich mich an das Event “kernel.request” gehängt, das noch vor dem Kontrolleraufruf verarbeitet werden kann.

Einen speziellen Listener hatte ich erst dazwischen, habe es dann später aber wieder etwas vereinfacht. Mein Code entspricht vielleicht nicht allen Symfony-Richtlinien, aber zum Arbeiten und Erklären reicht es aus.

Zum Verarbeiten der Annotations habe ich eine einfache Klasse aufgebaut und mich dabei an den “Route()”-Annotations orientiert. Die Methode “findClass()” ist aus bestehendem Code “recycled”, da sie anders schwerer erreichbar wäre.

<?php
namespace MyNamespace\Annotations;

use Doctrine\Common\Annotations\Reader;
use Symfony\Component\EventDispatcher\EventDispatcher;

class AnnotatedEventClassLoader
{
  private $reader;
  private $eventDispatcher;
  private $eventAnnotationClass  = 'MyNamespace\\Annotations\\Event';

  /**
   * Constructor
   *
   * @param    Reader $reader
   * @param    EventDispatcher $eventDispatcher
   * @return    void
   */
  public function __construct(
    Reader $reader, EventDispatcher $eventDispatcher) {
    $this->reader = $reader;
    $this->eventDispatcher = $eventDispatcher;
  }

  public function init() {
    $listenersDir = realpath(__DIR__ . '/../../Listener');

    $iterator = new \RecursiveIteratorIterator(
      new \RecursiveDirectoryIterator($listenersDir),
        \RecursiveIteratorIterator::LEAVES_ONLY);

    foreach ($iterator as $file) {
      if (!$file->isFile() || '.php' !== substr($file->getFilename(), -4)) {
        continue;
      }

      if ($class = $this->findClass($file)) {
        $reflClass = new \ReflectionClass($class);
        if ($reflClass->isAbstract()) { continue; }

        foreach($reflClass->getMethods() as $method) {
          $annotation = $this->reader->getMethodAnnotation($method, $this->eventAnnotationClass);
          if (!$annotation instanceof Event || empty($annotation)) { continue; }
          $this->registerEvents($annotation, $class, $method->getName());
        }
      }
    }
  }

  /**
   *
   * @param    \MyNamespace\Annotations\Event $eventAnnotation
   * @param    string|object $class
   * @param    string $method
   * @return   \MyNamespace\Annotations\AnnotatedEventClassLoader
   */
  public function registerEvents($eventAnnotation, $class, $method) {
    $listener = is_object($class) ? $class : new $class();

    foreach ($eventAnnotation->getEvents() as $event) {
      $this->eventDispatcher->addListener(
        $event, array($listener, $method), $eventAnnotation->getPriority()
      );
    }
    return $this;
  }

  /**
   * Returns the full class name for the first class in the file.
   *
   * @param string $file A PHP file path
   *
   * @return string|false Full class name if found, false otherwise
   */
  protected function findClass($file) {
    $class = false;
    $namespace = false;
    $tokens = token_get_all(file_get_contents($file));
    for ($i = 0, $count = count($tokens); $i < $count; $i++) {
      $token = $tokens[$i];

      if (!is_array($token)) { continue; }

      if (true === $class && T_STRING === $token[0]) {
        return $namespace.'\\'.$token[1];
      }

      if (true === $namespace && T_STRING === $token[0]) {
        $namespace = '';
        do {
          $namespace .= $token[1];
          $token = $tokens[++$i];
         } while ($i < $count && is_array($token) && in_array($token[0], array(T_NS_SEPARATOR, T_STRING)));
       }

       if (T_CLASS === $token[0]) {
         $class = true;
       }

       if (T_NAMESPACE === $token[0]) {
         $namespace = true;
       }
     }

     return false;
   }
}

Damit der Loader später auch seinen Dienst tut, muss er noch als Listener für das “kernel.request”-Event bekannt gemacht werden. Dafür habe ich die Datei “app/config/annotations.xml” mit folgendem Inhalt angelegt.

<?xml version="1.0" ?>

<container xmlns="http://symfony.com/schema/dic/services"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd">

  <parameters>
    <parameter key="myapp.event.loader.class">MyNamespace\Annotations\AnnotatedEventClassLoader</parameter>
  </parameters>

  <services>
    <service id="myapp.event.loader">
      <tag name="kernel.event_listener" event="kernel.request" method="init" />
      <argument type="service" id="annotation_reader" />
      <argument type="service" id="event_dispatcher" />
    </service>
  </services>
</container>

Die Konfiguration muss dann auch noch der AppKernel-Klasse mitgeteilt werden und damit ist der Loader eingebunden.

class AppKernel extends Kernel {
  // other methods...

  public function registerContainerConfiguration(LoaderInterface $loader) {
    // ...
    $loader->load(__DIR__ . '/config/annotations.xml');
  }
}

Annotations werden durch eigene Klassen verarbeitet und können dadurch mit beliebiger Logik versehen werden. Alles was einer Annotation als Parameter mitgegeben wird, bekommt die Klasse als Array im Constructor übergeben.

Für die Registrierung von Eventlistener brauchte ich nur die Events, die hier kommasepariert übergeben werden und gegebenenfalls noch die Priotität, in dem Fall optional. Die Klasse selber wird auch durch eine Annotation als solche gekennzeichnet.

<?php
namespace MyNamespace\Annotations;

/**
 * @Annotation
 */
class Event {
  private $events = array();
  private $priority = 0;

  public function __construct($options) {
    if (isset($options['value'])) {        
      $this->setEvents($options['value']);
    }

    $this->setPriority(
      isset($options['priority']) ? $options['priority'] : 0 );
  }

  public function getEvents() {
    return $this->events;
  }

  public function setEvents($events) {
    if(!is_array($events)) {
      $events = array_map('trim', explode(',', $events));
    }
    $this->events = $events;
    return $this;
  }

  public function getPriority() {
    return $this->priority;
  }

  public function setPriority($priority) {
    $this->priority = (int)$priority;
      return $this;
  }
}

Nun sollte alles an PHP-Code und Konfiguration an seinem Platz sein, aber wie funktioniert das jetzt genau?

Durch das Event wird der Loader benachrichtigt, dass die Listener initialisiert werden sollen. Dazu wird das Verzeichnis “Listener” nach Klassen mit Annotations durchsucht, welche dann von der Annotation-Event-Klasse verarbeitet werden. Innerhalb des Loader werden dann die Listener für die Events registriert und können von da an verwendet werden.

Die Untersuchung des PHP-Codes funktioniert mit Reflections, was ansich immer den Ruf hat langsam zu sein. Der AnnotationReader verfügt über ein eigenes Caching und macht sich daher zeitlich nicht negativ bemerkbar.

Der Loader durchsucht das gesamte Verzeichnis in beliebiger Tiefe nach Dateien, daher bleibt man in der Namensvergabe frei.

Ein Listener könnte dann zum Beispiel so aussehen:

<?php
namespace MyNamespace\Bundle\Listener\Deep\Folder\Structure\Test;

use MyNamespace\Annotations\Event;

class Listener {
    /**
     * @Event("foo.bar, bar.foo", priority="1")
     * @param type $event
     */
    public function onFooBar1($event) {
        echo __METHOD__;
    }

    /**
     * @Event("foo.bar", priority="20")
     * @param type $event
     */
    public function onFooBar2($event) {
        echo __METHOD__;
    }
}

Ein Aufruf aus dem Kontroller funktioniert dann wie gewohnt über den EventDispatcher, der fast überall als Service erreichbar ist.

public function indexAction() {        
  $this->get('event_dispatcher')->dispatch('foo.bar');
}

// oder

public function indexAction() {
  $someEvent = new SomeEvent();       
  $this->get('event_dispatcher')->dispatch('foo.bar', $someEvent);
}

Wie gesagt sind das meine ersten Versuche mit Symfony und der Code ist nicht optimiert. Die Funktionen des Loaders sollten noch weiter in Unterobjekte verteilt werden, damit das ganze noch flexibler wird und auch der gecodete Teil mit dem Verzeichnisnamen ist verbesserungfähig.

Ich konnte dabei wieder ein paar Sachen lernen und vielleich spart es ja dem einen oder anderen von euch etwas Zeit, falls ihr das braucht.

<?php
App::import('model','Bar');

class Foo extends AppModel {
  public $Bar;
        
  public function __construct($id = false, $table = null, $ds = null) {
    parent::__construct($id, $table, $ds);
    $this->Bar = new Bar();
  }      
}

Danach wie gewohnt aufrufen.

<?php
$this->Bar->find();

Bislang musste man Callback-Funktionen gewöhnlich definieren, bevor man sie verwenden konnte.

<?php
function myCallback($output) {
  return '##' . $output . '##';
}

echo call_user_func('myCallback', 'Hallo Welt');

// Ausgabe:
##Hallo Welt##

Als Closure geschrieben sähe das dann so aus:

<?php
echo call_user_func(
  function($output) { return '##' . $output . '##'; },
  'Hallo Welt');

// Ausgabe:
##Hallo Welt##

Zugegeben, dieses Beispiel hätte man durch einfache Stringverkettung wesentlich einfacher schreiben können und eigentlich war das mit create_function() auch schon unter PHP4 möglich.

Wir können die Funktion natürlich wie früher auch schon in einer Variablen speichern und dann weiter verwenden.

<?php
$myFunction = function($output) {
  return '##' . $output . '##';
};

echo call_user_func($myFunction, 'Hallo Welt') . '<br/>';
echo $myFunction('Hallo Welt') . '<br/>';

//Ausgabe:
##Hallo Welt##
##Hallo Welt##

Und auch das ist ja noch nichts Neues. Mit Closures haben wir nun aber auch die Möglichkeit, teile unserer “Umgebung” zum Zeitpunkt der Funktionsdefinition zu konservieren.

Dazu müssen wir nur die Definition etwas erweitern.

<?php
$before = '>';
$after = '<';

$myFunction = function($output) use ($before, $after) {
    return $before . $output . $after;
};

echo $myFunction('Hallo Welt') . '<br/>';

//Ausgabe:
>Hallo Welt<

An dieser Stelle frieren wir mit “use” sozusagen die Werte für $before und $after innerhalb unserer Funktion ein. Spätere Änderungen der beiden Variablen haben keine Auswirkungen auf die Funktion.

$before = 'foo';
$after = 'bar';
echo $myFunction('Hallo Welt') . '<br/>';

//Ausgabe:
>Hallo Welt<

In PHP wir mittlerweile sehr viel mit Standardinterfaces und -klassen (SPL) abgedeckt und so ist es auch in diesem Fall. In der Variablen $myFunction ist ein Objekt vom Typ “Closure” gespeichert.

<?php
echo '<pre>' . print_r($myFunction, true) . '</pre>';

//Ausgabe:
Closure Object
(
  [static] => Array
    (
      [before] => >
      [after] => <
    )
  [parameter] => Array
    (
      [$output] =>
    )
)

Will man eigene Objekte wie Funktionen aufrufen, dann geht das mit der magischen Methode __invoke(), die auch hier verwendet wird.

Anfangs erwähnte ich, dass Closure-Callbacks zur Filterung, aber auch zur Manipulation von Array verwendet werden können.

Wenn nur der Inhalt interessant ist, dann kommen wir mit array_map() und einem Parameter aus.

<?php
$values = array(
  array(
    'a' => array(
      'b' => 'foo'
    )
  ),
  array(
    'a' => array(
      'b' => 'bar'
    )
  ),
);

$filtered = array_map(
  function ($item) { return $item['a']['b']; },
  $values
);
echo '<pre>' . print_r($filtered, true) . '</pre>';

// Ausgabe:
Array
(
  [0] => foo
  [1] => bar
)

Wollen wir aber Werte im Array in Abhängigkeit zum Key/Index verändern, dann geht das mit array_walk und einem zweiten Parameter im Callback. Bei beiden kann natürlich auch “use” verwendet werden. Der Parameter $value wird dabei als Referenz übernommen.

$values = array(
  'a' => 100,
  'b' => 200,
  'c' => 300,
);

array_walk(
  $values,
  function (&$value, $key) {
    if ('b' == $key) {
      $value = 42;
    }
  }
);

echo '<pre>' . print_r($values, true) . '</pre>';

// Ausgabe:
Array
(
  [a] => 100
  [b] => 42
  [c] => 300
)

Ich hoffe, dass ich ein wenig Licht ins Dunkel bringen konnte und “Closure” nun kein geheimnisvolles Zauberwort mehr ist.

Wenn ihr noch gute Ergänzungen oder Anwendungbeispiele habt, dann immer her damit und bitte fleissig kommentieren.

• Onlinetool zum (Neu-)Formatieren von JavaScript-Code
  http://jsbeautifier.org/
• PHP Benchmark gibt einen Überblick über die Performance vergleichbarer Operationen
  http://www.phpbench.com/
• Responsive Design/Layout-Tester (siehe auch meinen Neujahrsartikel )
  http://mattkersley.com/responsive/