3.5 Erweiterte Möglichkeiten 
Mit den in diesem Kapitel verwendeten Komponenten haben Sie nun bereits einige Erfahrungen gesammelt. Dennoch bieten Ihnen beide weitere Möglichkeiten an, die im GP-Blog nicht ausgereizt werden, weshalb wir sie hier kurz vorstellen möchten.
3.5.1 Ungeordnete Parameter 
Wie wir bereits in Abschnitt 3.3.5, »Laufen lassen«, kurz erwähnt haben, unterstützt die Url-Komponente nicht nur geordnete Parameter, sondern auch ungeordnete. Letztere benötigen zur Identifizierung innerhalb der URL einen Namen, der sie eindeutig identifiziert und der auf irgendeine Art und Weise von den Werten des Parameters innerhalb der URL abgegrenzt werden muss. Standardmäßig fasst ezcUrl den Parameternamen in runde Klammern, die verwendeten Zeichen können Sie jedoch selbst an Ihren Geschmack anpassen:
$urlCfg = new ezcUrlConfiguration();
$urlCfg->basedir = 'mydir';
$urlCfg->script = 'index.php';
$urlCfg->unorderedDelimiters = array( ';', ';' );
$urlCfg->addUnorderedParameter(
'ids',
ezcUrlConfiguration::MULTIPLE_ARGUMENTS
);Listing 3.16 Konfiguration der Url-Komponente mit ungeordneten Parametern
Eine so konfigurierte URL müsste die folgende Gestalt haben, um erfolgreich verarbeitet zu werden:
http://example.com/myscript/index.php/;ids;/23/42/5
Der Parameter ids kann mehrere Werte übertragen, was bei geordneten Parametern nicht möglich ist. Wie konfiguriert, wird der Name des Parameters durch Semikola abgegrenzt. Die Werte des Parameters sind an dieser Stelle 23, 42 und 5. Werden mehrere Werte mit einem Parameternamen assoziiert, gibt Ihnen die getParam()-Methode ein Array zurück.
3.5.2 URLs verwalten
Die Url-Komponente stellt Ihnen neben den bereits vorgestellten Klassen noch eine weitere Klasse bereit: ezcUrlCreator. Mit Hilfe eines Objekts dieser Klasse wird es Ihnen ermöglicht, eine Sammlung von URL-Strings zentral zu verwalten und an anderer Stelle wieder abzurufen.
ezcUrlCreator::registerUrl(
'image',
'/images/%s?xsize=%d&ysize=%d'
);
// An anderer Stelle...
echo ezcUrlCreator::getUrl( 'image', 'photo.jpg', 450, 450 );Listing 3.17 URL mit Parametern erstellen
Zuerst wird eine URL unter dem Namen image registriert. An anderer Stelle der Applikation können Sie diese dann mit ihrem Namen ansprechen. Eine registrierte URL kann Platzhalter enthalten, wie sie in der PHP-Funktion sprintf() [http://php.net/sprintf ] verwendet werden. Diese Platzhalter werden beim Abruf der URL befüllt. Der Codeschnipsel würde also Folgendes ausgeben:
/images/photo.jpg?xsize=450&ysize=450
Sie erhalten also die Möglichkeit, URLs an zentraler Stelle zu definieren und innerhalb der Anwendung an beliebiger Stelle abzurufen. So müssen Sie bei einer Änderung der URL-Struktur lediglich an einer einzigen Stelle Änderungen vornehmen und müssen somit nicht den gesamten Quellcode durchsuchen.
3.5.3 Signale priorisieren
Während im Galileo-Press-Blog lediglich einfache Signale verwendet werden und pro Slot bisher nur eine verarbeitende Methode gelauscht hat, bietet Ihnen die SignalSlot-Komponente auch die Möglichkeit, mehrere Funktionen auf einen Slot zu konnektieren und diese Verbindungen sogar zu priorisieren:
$mainSignals()->connect(
"error",
array( "gpBlogErrorHandler", "handleError" ),
10
);
$mainSignals->connect(
"error",
array( "gpBlogErrorLogger", "logError" ),
20
);Listing 3.18 Priorisierte Slots
In diesem Beispiel werden zwei Methoden an den Slot error gekoppelt. Zunächst die Methode handleError() der fiktiven Klasse gpBlogErrorHandler, danach die Methode logError() der (ebenfalls fiktiven) Klasse gpBlogErrorLogger. Da der zweite Aufruf einen höheren Prioritätswert übergibt als der erste, würde beim Senden des error-Signals zuerst die Methode logError()aufgerufen, danach erst die Methode handleError().
Die Verbindung mehrerer Funktionen mit einem Slot ist durchaus üblich und wird im späteren Verlauf des Buches noch häufiger auftauchen. Allerdings bringt die manuelle Priorisierung einige Nachteile mit sich. Generell sollte es egal sein, in welcher Reihenfolge ein Signal abgearbeitet wird. Verlassen Sie sich jedoch darauf, dass ein Signal von bestimmten Methoden zuerst verarbeitet wird und registrieren Sie für seinen Slot mehrere Funktionen an verschiedenen Stellen Ihrer Applikation, kann es schnell passieren, dass Sie den Überblick verlieren. Eine solche Konstruktion zu debuggen, kann sehr schnell in wirkliche Arbeit ausarten. Von der manuellen Priorisierung von Slots ist also abzuraten, solange es nicht unbedingt nötig ist. Jedoch können Sie im Falle, dass zwei Methoden die gleiche Priorität haben, keine zuverlässige Annahme darüber treffen, welche zuerst aufgerufen wird.
3.5.4 Statische Signale
Sämtliche Aktionen im GP-Blog greifen auf zwei globale Signalsammlungen zu. Dies ist sinnvoll, da mit Hilfe von SignalSlot die Kommunikation zwischen den Komponenten des MVC-Entwurfsmusters implementiert wurde. In den meisten Fällen werden Sie aber mehrere Komponenten haben, die unabhängig voneinander eigene Signalsammlungen bereitstellen, zum Beispiel in einem Plug-in- oder Widget-System. Gesetzt den Fall, Sie haben in Ihrer Applikation viele Instanzen einer einzigen Klasse, welche Signale verarbeiten sollen, so müssten Sie für jede dieser Instanzen die Verbindung der Slots manuell vornehmen. Dies ist sehr unhandlich, weshalb SignalSlot Ihnen den Mechanismus statischer Signale zur Verfügung stellt.
class gpBlogEntry
{
public $signals = null;
private $id;
public function __construct( $id )
{
$this->id = $id;
$this->signals = new ezcSignaCollection( __CLASS__ );
}
public function save()
{
$this->signals()->emit( "saved", $this->id );
}
}
class gpBlogCache
{
public function purgeCache( $id )
{
echo "Purging cache for entry ID: {$id}\n";
}
}
$cache = new gpBlogCache();
ezcSignalStaticConnections::getInstance()->connect(
"gpBlogEntry",
"saved",
array( $cache, "purgeCache" )
);
$data1 = new gpBlogEntry( 1 );
$data2 = new gpBlogEntry( 2 );
$data1->save();
$data2->save();Listing 3.19 Statische Signale
In diesem Beispiel wird eine kleine Klasse gpBlogEntry implementiert, die fiktiv einen Eintrag des Galileo-Press-Blogs darstellen soll. Sie besteht nur aus einer ID und einer Signalsammlung, die an dieser Stelle mit einem Namen versehen wird. Der Name ist notwendig, um später statische Slots mit der Sammlung verbinden zu können. Des Weiteren implementiert die Klasse eine Methode save(), welche ein Signal sendet.
Die zweite Klasse im Beispiel soll einen rudimentären Cache darstellen, der für jeden Eintrag statische Daten speichert. Das Ziel für SignalSlot ist es nun, den Cache zu benachrichtigen, sobald ein Eintrag geändert wird, damit die statischen Daten gelöscht werden können. Verwendet man SignalSlot, wie Sie es bisher kennengelernt haben, wäre es notwendig, die Instanz des gpBlogCache manuell zum Slot jedes Eintragsobjekts zu verbinden. Um Ihnen diese Arbeit zu ersparen, wird hier die Klasse ezcSignalStaticConnections verwendet. Von ihr existiert global nur eine einzige Instanz (Stichwort Singleton), die mit Hilfe der statischen Methode getInstance() abgerufen werden kann. Die Methode connect() auf dem statischen Signal-Objekt hat eine ähnliche Signatur wie die gleichnamige Methode auf ezcSignalCollection, allerdings mit dem Unterschied, dass als erster Parameter der Name der anzusprechenden Signalsammlung angegeben wird. Es werden also global verschiedene Slot-Sammlungen in einem einzigen Objekt verwaltet, wobei jede Sammlung eindeutig über ihren Namen identifiziert werden kann. Zuvor wurde eine entsprechende Signalsammlung mit dem Namen gpBlogEntry angelegt, der hier erneut verwendet wird, um auf die Sammlung zuzugreifen. Danach folgt als zweiter Parameter wie gewohnt der Name des zu verbindenden Slots, gefolgt von der eigentlichen Verbindung.
Zuletzt werden in diesem Beispiel zwei unterschiedliche Instanzen von gpBlogEntry erzeugt und jeweils save() auf ihnen aufgerufen. In beiden Fällen wird das Signal saved gesendet und der entsprechende Slot des gpBlogCache-Objekts angesprochen, ohne dass diese Verbindung für jedes Eintragsobjekt explizit hergestellt wurde. Die Verbindung ist also statisch, sozusagen mit der Klasse gpBlogEntry zustandegekommen und nicht mit einem spezifischen Objekt.
Sie können in Ihrer Applikation statische und dynamische Verbindungen bunt mischen, wenn dies erforderlich sein sollte. SignalSlot unterscheidet sie intern nicht. Beide Signalformen werden gleich verarbeitet und kommen sich nicht gegenseitig ins Gehege.
3.5.5 Lazy-Initialization für SignalSlot
In Abschnitt 2.3.4, »Lazy-Initialization«, haben Sie bereits das Grundkonzept der Lazy-Initialization kennengelernt. PersistentObject ist eine der Komponenten, die diesen Mechanismus unterstützt und Ihnen somit die Möglichkeit bietet, die Komponente erst bei Verwendung initialisieren und konfigurieren zu lassen. Allerdings macht dieser Mechanismus im GP-Blog keinen Sinn, da jeder einzelne Request über die SignalSlot-Komponente abgewickelt wird. Verwenden Sie SignalSlot allerdings in der Form, dass Sie eine Plug-in-Architektur damit realisieren, ist es durchaus angebracht, die Komponente nicht zu initialisieren, falls keine Plug-ins gefunden werden oder im aktuellen Request gar keine Plug-ins eingreifen können.
class customLazySignalConfiguration
{
public static function configureObject( $signal )
{
$signal->connect(
'default',
'signal',
'customFunction'
);
}
}
ezcBaseInit::setCallback(
'ezcInitSignalStaticConnections',
'customLazySignalConfiguration'
);
function customFunction()
{
echo "Custom function called with:\n";
var_export( func_get_args(), true );
}
$signals = new ezcSignalCollection();
$signals->emit( 'signal', 42 );Listing 3.20 Lazy-Initialization für SignalSlot
Zunächst wird die Konfigurationsklasse erzeugt, welche die Base-Komponente (Kapitel 2, »Einführung in eZ Components«) zur Konfiguration von SignalSlot verwenden soll. Innerhalb der configureObject()-Methode wird entsprechend ein Slot registriert, der später zur Verfügung stehen soll und auf die Funktion customFunction() zeigt. Diese Funktion tut exemplarisch nichts anderes, als einen Text und die ihr übergebenen Daten auszugeben. ezcBaseInit wird mitgeteilt, dass die Klasse customLazySignalConfiguration zur Konfiguration von statischen Signalen herangezogen werden soll.
In den letzten zwei Zeilen dieses Beispiels wird eine Signalsammlung erzeugt und das Signal signal gesendet. Der Lazy-Initialization-Mechanismus konfiguriert hierbei die gewünschten Signale automatisch, sodass sie direkt verwendet werden können. Wird allerdings in einem Request keine Signalsammlung verwendet, werden dementsprechend keine Slots konfiguriert.
