8.3 Integration in das Blog 
Wenn eine Action-Methode etwas darstellen will, sendet diese Methode das Signal show_entry mit den darzustellenden Variablen als Parameter. Das Signal ist an die Methode gpBlogController::display() gebunden. Die bisherige Implementierung in dieser Methode wird in diesem Kapitel vollständig durch die Verwendung der Template-Komponente ersetzt.
8.3.1 Initialisierung der Template-Komponente 
Um ein Template anzuzeigen, wird die Komponente initialisiert und konfiguriert.
public function display( $name, array $params )
{
$template = new ezcTemplate();
$config = ezcTemplateConfiguration::getInstance();
$config->templatePath =
dirname( __FILE__ ) . '/../templates';
$config->compilePath =
dirname( __FILE__ ) . '/../templates_compiled';
$config->context = new ezcTemplateXhtmlContext();
// ...
}Listing 8.1 Beginn der neuen display()-Methode
Die Methode bekommt als Parameter den Namen des Templates und die übergebenen darzustellenden Inhalte. Nach der Initialisierung der Komponenten in der dritten Zeile des Beispiels wird über eine Registry, deren Mechanismus in Abschnitt 6.4, »Integration von Database«, näher beschrieben wurde, eine Instanz der Klasse ezcTemplateConfiguration bezogen. In diesem Kapitel werden wir nur eine Konfiguration verwenden, weswegen wir die Default-Instanz verwenden können. Falls beim Interpretieren des Templates eine andere als die Default-Instanz von ezcTemplateConfiguration verwendet werden soll, kann diese beim späteren Aufruf von process() auf dem Template-Objekt explizit angegeben werden.
Über die Eigenschaft $templatePath wird der Komponente mitgeteilt, wo sich die Templates befinden. Das Verzeichnis, das der Eigenschaft $compilePath zugewiesen wird, sollte durch den Benutzer des Webservers schreibbar sein, da hier die kompilierten Templates abgelegt werden. Die beiden Verzeichnisse templates/ und templates_compiled/ liegen im Wurzelverzeichnis der Blog-Applikation und sind entsprechend referenziert.
In der neunten Zeile des Listings wird der Kontext der Ausgabe über die Eigenschaft $context gesetzt. Diese Zeile ist redundant, da der gesetzte Kontext bereits dem Default-Kontext entspricht. Sie zeigt aber, wie sich der Kontext der Ausgabe für andere Ausgabeformate verändern lässt. Aktuell sind lediglich zwei Kontexte verfügbar, jedoch können jederzeit eigene Ableitungen von ezcTemplateOutputContext erstellt werden.
- ezcTemplateXhtmlContext Sorgt für die Maskierung von gefährlichen Zeichen bei der Ausgabe von HTML oder XHTML.
- ezcTemplateNoContext Es werden keine Zeichen maskiert, was bei der Ausgabe von Text oder anderen Formaten ohne aktive Inhalte sinnvoll ist.
8.3.2 Übergabe von Inhalten an das Template
Nach der Konfiguration der Template-Komponente müssen die darzustellenden Inhalte an das Template übergeben werden.
// Register action template variables
foreach ( $params as $key => $value )
{
$template->send->$key = $value;
}Listing 8.2 Variablen an das Template übergeben
Zur Kommunikation zwischen Applikation und Template implementiert die Template-Komponente zwei Interfaces, die über die Eigenschaften $template->send und $template->receive angesteuert werden. Wie es die Namen nahelegen, lassen sich über die Eigenschaft $send Variablen an das Template übergeben, und über $receive Rückgaben aus dem Template auslesen.
Um alle relevanten Variablen an das Template zu übergeben, wird mit foreach über das Array mit den Inhalten iteriert und der Inhalt in der vierten Zeile in einer Template-Variablen mit dem Namen des Schlüssels registriert.
Auf den Umgang mit der Eigenschaft $receive wird noch später in diesem Kapitel in Abschnitt 8.4.1, »Rückgaben verarbeiten«, eingegangen. Da wir keine Rückgaben aus dem Template verarbeiten wollen, spielt es bei der Einbindung der Komponente in das Blog keine Rolle.
8.3.3 Wichtige Variablen
Um das Template-System in das Blog zu integrieren, müssen noch diverse Einstellungen des Blogs bekanntgemacht werden, damit sie auch im Template verwendet werden können.
// Register site settings
$site = $cfg->getSettings(
'site',
'general',
array( 'name', 'title', )
);
$site['basedir'] = $cfg
->getSetting( 'site', 'installation', 'basedir' );
$site['base'] = $site['basedir'] .
$cfg->getSetting( 'site', 'installation', 'script' ) . '/';
foreach ( $site as $key => $value )
{
$template->send->$key = $value;
}Listing 8.3 Entscheidende Applikationsvariablen übergeben
Wie in Kapitel 5, »Konfiguration«, beschrieben, werden mit Hilfe der Configuration-Komponente, Einstellungen wie der Name des Autors und der Titel des Blogs ausgelesen und im Array $site gespeichert. Dazu kommen noch das $basedir des Blogs, um in den Templates korrekte URLs zu Bildern und Stylesheets aufbauen zu können, sowie $base, das $basedir mit dem Skriptnamen verbindet, um in den Templates einfach absolute URLs zu anderen Seiten des Blogs zu erstellen. Die Variablen im Array $site werden wie im letzten Beispiel beim Template registriert.
8.3.4 Ausgabe
Das Kompilieren und Interpretieren des Templates passiert vollständig hinter der Kulisse der Template-Komponente und bedarf keines weiteren Wissens oder Einflusses durch den Benutzer der Komponente.
echo $template->process( 'pagelayout.ezt' );
Die Methode ezcTemplate::process() gibt einen String mit der Ausgabe des Templates zurück, der in der Applikation direkt ausgegeben oder weiterverwendet werden kann. Als Parameter akzeptiert die Methode den Namen des zu verarbeitenden Templates, der sich aus dem Namen mit der Dateiendung ezt für eZ Template zusammensetzt.
8.3.5 Template-Struktur im Blog
Die Struktur der Applikation, wie in Kapitel 3, »Die Applikationsbasis«, beschrieben, ist auf eine zentrale Aktion ausgerichtet, die über die URL aufgerufen worden ist. Diese Aktion beendet die in ihr implementierte Applikationslogik entweder mit dem Weiterleiten zu einer anderen Aktion, zum Beispiel nach dem erfolgreichen Einfügen eines Blog-Eintrags zur Seite mir einer Erfolgsmeldung, oder zeigt die von der Aktion verarbeiteten Daten an.
Das Template, das die Aktion zur Ausgabe der verarbeiteten Daten verwendet, bestimmt die Aktion selbst. Um ein in der Webapplikation einheitliches, leicht durch einen Webdesigner veränderbares Layout zu ermöglichen, wird das Action-Template in ein umfassendes Template eingebunden, pagelayout genannt, das Menü, Kopf und Fuß der Seite darstellen soll. Die in diesem Template dargestellten Inhalte sollen universell für die gesamte Webapplikation sein.
Wenn ein anderes umgebendes Template benötigt wird, zum Beispiel für ein Pop-Up mit einem schlichterem Layout oder für einen anderen Bereich der Seite, kann das pagelayout-Template durch die Aktion oder andere Applikationsmechanismen konfigurierbar gemacht werden.
8.3.6 Das pagelayout-Template
Nachdem die Einbindung des Template-Systems in die Applikation beschrieben ist, müssen die Templates nun selbst geschrieben werden. Wir beginnen mit dem umgebenden pagelayout-Template, das auf jeder aufgerufenen Seite zu sehen sein wird.
{use $name, $title, $basedir, $base,
$charset = 'utf-8',
$headline = $title,
$module}Listing 8.4 Variablen in das Template importieren
Die Template-Komponente forciert die Deklaration der Variablen, die in einem Template verwendet werden sollen, im Kopf des Templates. Dies hat sich in der Entwicklung mit vielen Templates in eZ Publish, besonders in der Modifikation von Templates, die jemand Anderes erstellt hat, als sinnvoll erwiesen. Ohne eine explizite Deklaration war es oftmals nicht klar ersichtlich, welche Variablen immer zur Verfügung stehen, welche je nach Aktion/Modul zur Verfügung stehen, oder welche im aktuellen Template oder einem übergeordneten Template selbst definiert worden sind.
Beim Importieren der Variablen in das aktuelle Template kann eine Standardbelegung definiert werden, falls die Variable nicht in jedem Fall definiert wird. Falls die Variable nicht definiert und keine Standardbelegung definiert wurde, wird eine ezcTemplateRuntimeException geworfen, die Sie darüber informiert, welche Variable nicht gesetzt ist. Bei der Definition der Standardbelegung kann auch, wie im obigen Beispiel zu sehen ist, auf eine bereits zuvor importierte Variable zurückgegriffen werden.
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type"
content="text/html; charset={$charset]" />
<link rel="Stylesheet" type="text/css"
href="{$basedir}stylesheets/galileo.css"
media="screen" />
<title>{$headline}</title>
</head>Listing 8.5 Kopf des Templates
Nach dem Import der Variablen folgt die Ausgabe des typischen HTML-Kopfes. In dieser Ausgabe werden nun auch einige der zuvor importierten Variablen verwendet. Um Variablen in einem Template auszugeben, kann die sehr kurze Syntax {$variable} verwendet werden. Wenn Sie sich an die zuvor beschriebenen Ausgabekontexte erinnern, wissen Sie, dass diese Ausgabe von beliebigen Inhalten in der Variablen kein HTML oder andere aktive Inhalte einschleusen kann.
Die Variable $basedir vor dem Pfad des Stylesheets und des Favicons enthält den absoluten Pfad zum Wurzelverzeichnis des Blogs und wurde in der Applikation auf Basis der Konfigurationseinstellungen gesetzt. Die Verwendung vor allen Pfaden lässt das Blog unabhängig vom Installationsort die richtigen Dateien verwenden. Im späteren Verlauf des Kapitels zeigen wir, wie sich eigene Template-Funktionen definieren lassen, durch die die Verwendung der Variablen ersetzt werden sollte, was wir jedoch an dieser Stelle unterlassen, um das Beispiel einfach zu halten.
<body>
<div class="header">
<a href="{$base}">
<h1>{$title}</h1>
</a>
<a href="http://www.galileo-press.de/">
<img id="logo"
src="{$basedir}images/galileo_press.png"
alt="Galileo Press" width="192" height="60" />
</a>
<h2>by {$name}</h2>
</div>
<div class="content">
{* Ausgabe des Modulinhaltes *}
{raw $module}
</div>
<div class="footer">
Galileo Press Blog powered by
<a href="http://components.ez.no/">eZ Components</a>
</div>
</body>
</html>Listing 8.6 Template-Rumpf
Das pagelayout-Template enthält keine Darstellungslogik, sodass auch im weiteren Verlauf des Templates nur einige der vorher importierten Variablen ausgegeben werden.
Eine Besonderheit bei der Ausgabe zeigt sich in Zeile 14 des letzten Template-Extrakts – {raw $module}. Da in das pagelayout-Template die Rückgabe der Templates, die die Aktionen zur Darstellung ihrer Inhalte verwendeten, integriert werden soll, darf an dieser Stelle HTML nicht maskiert werden, sondern muss direkt ausgegeben werden. Unter Verwendung des Schlüsselworts raw lassen sich Inhalte somit unmaskiert ausgeben. Die Notwendigkeit es explizit anzugeben, macht jedem Entwickler von Templates bewusst, dass derartig ausgegebene Inhalte aus einer sicheren Quelle stammen sollten.
Kommentare können (wie im Beispiel zu sehen) entweder in {* und *} gefasst werden oder (wie aus C++ und PHP bekannt) innerhalb von Template-Code in /* und */ gefasst werden. Beide Möglichkeiten, Kommentare zu verwenden, können auch für mehrzeilige Kommentare benutzt werden und erscheinen weder im HTML- noch im kompilierten PHP-Code.
8.3.7 Einbinden von Modul-Templates in die Applikation
Der letzte Abschnitt zeigte bislang nur die Ausgabe des pagelayout-Templates. Um darstellbare Inhalte aus den Modulen zu beziehen, wird zuerst das Modul-Template aufgerufen und dessen Rückgabe dann an das pagelayout-Template geschickt.
// Process module template
$template->send->module = $template->process(
$name . '.ezt' )
);
// Use returned title as headline
$template->send->headline = $template->receive->title;
// Show page
echo $template->process( 'pagelayout.ezt' ) ;Listing 8.7 Modul-Template einbinden
Um die Rückgabe des Modul-Templates im pagelayout-Template zur Verfügung zu stellen, wird die Rückgabe des Modul-Templates erneut einer neuen Template-Variablen zugewiesen. Templates können nicht nur über die Eigenschaft send Variablen geschickt bekommen, sondern auch explizit Werte zurückgeben. Sie erinnern sich an die Variable $headline mit einem Fallback auf den Inhalt von $title? Diese kann von einem Modul-Template geändert werden und wird in diesem Fall der Variable $headline zugewiesen. Der Abschnitt 8.4.1, »Rückgaben verarbeiten«, zeigt, wie diese Rückgabe aus dem Template heraus funktioniert.
Include zum Einbinden der Modul-Templates
Sie mögen sich die Frage stellen, warum wir das Modul-Template nicht über einen include-Block einbinden. Das hat zum einen den Grund, dass die Template-Komponente mit dem klaren Zeil entwickelt wurde, dass die verwendbaren Variablen explizit angegeben werden müssen, und entsprechend ist es nicht möglich, alle Variablen eines Modules aus dem pagelayout-Tempalte gesammelt an das eingebundene Modul-Template zu übergeben. Zum anderen wäre es nicht möglich gewesen, die im <title>-Element verwendete Variable durch das Modul-Template zu manipulieren, da dieses gewöhnlich ja erst im <body> eingebunden werden würde.
8.3.8 Liste der Blog-Einträge
Die Liste der Blog-Einträge enthält im Gegensatz zum zuvor gezeigten Template erstmals Darstellungslogik.
{use $entries, $base}
{if $entries}
<ul class="entry">
{foreach $entries as $entry }
<li>
<h3>
<a href="{$base}show_entry/{$entry->id}">
{$entry->title}
</a>
</h3>
<h4>{date_format_timestam('r', $entry->date)}</h4>
<p>
{raw $entry->body}
</p>
</li>
{/foreach}
</ul>
{/if}Listing 8.8 Template der Liste der Blog-Einträge
Aus dem Applikationskontext werden zu Beginn des Templates die Varibalen $base und $entries importiert. Während die erste den Basispfad enthält, um andere Einträge zu verlinken, enthält die zweite eine Liste der Blog-Einträge.
Die Syntax einer if-Abfrage ist einfach und setzt sich wie auch Schleifen oder das bereits bekannte raw aus dem Namen des Blocks und dem Parameter zusammen. In einer if-Abfrage ist der Parameter eine Bedingung, die, falls wahr, zur Ausführung des im if-Block eingeschlossenen Template-Codes führt.
Da die Bedingungen in PHP-Code übersetzt werden, sind die zu erwartenden Typkonvertierungen zu denen in PHP äquivalent. In diesem Fall enthält die Variable $entries entweder ein gefülltes Array, was nach der Konvertierung zu boolean dem Wert true entspricht, oder ein leeres Array oder null, was zu false konvertiert. Entsprechend wird die foreach-Schleife nur ausgeführt, wenn bereits Blog-Einträge existieren.
Auch die foreach-Schleife ähnelt ihrem PHP-Äquivalent. Sie iteriert über ein Array und stellt den aktuellen Wert sowie optional den aktuellen Schlüssel in einer Variablen innerhalb der Schleife zur Verfügung. Da in dem Array über die PersistentObject-Komponente erhaltene Objekte vorhanden sind, kann auf die Werte der einzelnen Einträge, wie aus PHP gewohnt, über den Objektzugriffsoperator -> zugegriffen werden. So wird in Zeile acht die ID des Blog-Eintrags verwendet, um den Link zur Vollansicht zu generieren, und darunter der Titel des Eintrags ausgegeben.
Unter dem Titel wird das Datum ausgegeben, das als Unix-Timestamp aus der Datenbank kommt. Die Template-Komponente stellt eine relativ umfangreiche Liste an Funktionen bereit, die zum größten Teil bekannten PHP-Funktionen entsprechen, aber einem einheitlichen Namensschema folgen. Zur Formatierung des Unix-Timestamps verwenden wir date_format_timestamp(), was der PHP-Funktion date() entspricht und die gleichen Format-Zeichen verwendet. Eine komplette Liste der Funktionen findet sich in der Dokumentation der Template-Komponente. [http://ezcomponents.org/docs/api/latest/Template_functions.html#date-format-%20timestamp ]
Um den Text des Blog-Eintrags auszugeben, wird erneut ein raw-Block verwendet. Denn in diesem Fall kann davon ausgegangen werden, dass der Eintrag aus einer vertrauenswürdigen Quelle stammt, dem Autor des Weblogs. Das Ergebnis inklusive Stylesheets und Bilder zeigt sich als Standardaktion unter der URL http://gpblog/.
Abbildung 8.1 Startseite mit einer Liste der Blog-Einträge
8.3.9 Vollansicht eines Blog-Eintrags
Das Template für die Vollansicht eines Blog-Eintrags gleicht weitestgehend dem Listing der Blog-Einträge und ist um Listen der Kommentare und Tags angereichert.
{use $entry, $comments, $tags, $title}
{if $tags}
<ul class="tags">
<li class="head">Tags</li>
{foreach $tags as $tag }
<li>{$tag->tag}</li>
{/foreach}
</ul>
{/if}Listing 8.9 Tag-Liste in der Blog-Vollansicht
Die Liste der Tags soll am rechten Rand des Blog-Eintrags erscheinen, wofür diese zuerst ausgegeben und über die CSS-Formatierungen dort positioniert wird. Wie auch im letzten Beispiel ist die Liste der Tags ein Array aus Objekten, die über die PersitentObject-Komponente geladen wurden und deren einzige aktuell relevante Eigenschaft, der Tag-Name, hier ausgegeben wird.
<h3>{$entry->title}</h3>
<h4>at {date_format_timestam('r', $entry->date)}</h4>
<p>
{raw $entry->body}
</p>Listing 8.10 Kopf der Blog-Vollansicht
Die hier folgende Ausgabe des Blog-Eintrags entspricht dem zuvor in der Blog-Liste gezeigtem.
{if $comments}
<ul class="comments">
{foreach $comments as $comment }
<li>
{include 'comment.ezt'
send $comment}
</li>
{/foreach}
</ul>
{/if}Listing 8.11 Blog-Kommentare ausgeben
Zur Darstellung der Kommentare eines Blog-Eintrags wird erneut über das Array mit den Kommentaren iteriert und diese in einer Liste ausgegeben. Zur Darstellung eines jeden Kommentars verwenden wir dabei ein eigenes Template, das auch an anderen Stellen wiederverwendet werden kann, an denen Kommentare darzustellen sind. Eingebundene Templates können mit Hilfe des Schlüsselwortes send Variablen übertragen und dabei auch umbenannt werden. Später in diesem Kapitel wird darauf noch genauer eingegangen. Das Template für einen einzelnen Kommentar gestaltet sich einfach:
{use $comment}
<h4>{$comment->name} at
{date_format_timestamp('r', $comment->date)}
</h4>
<p>
{$comment->body}
</p>Listing 8.12 Kommentar-Template
Der über send gesendete Kommentar wird über use importiert und seine Eigenschaften Name, Datum und Inhalt werden ausgegeben. Zur Ausgabe des Kommentartextes wird natürlich auf einen raw-Block verzichtet, da die Eingaben von potentiell vertrauensunwürdigen Besuchern der Webseite stammen. Mit Hilfe eines raw-Blocks könnten diese sonst HTML oder gar aktive Inhalte wie ECMAScript einschleusen.
Zum Ende des Templates für die Anzeige eines Blog-Artikels soll der Titel der Webseite angepasst werden, indem er durch den Titel des aktuell angezeigten Blog-Eintrags erweitert wird. Um das zu ermöglichen, können Templates nicht nur Daten über Variablen importieren, sondern auch beliebig viele Daten in die Applikation oder das aufrufende Template zurückschicken.
{return
$entry->title . ' – ' . $title as $title}Listing 8.13 Modifizierten Titel zurückgeben
Der neue Titel der Webseite, dessen Original zu Beginn des Templates importiert wurde, setzt sich aus dem Titel des Blog-Eintrags und dem originalen Titel zusammen und wird als Variable $title zurück an die Applikation geschickt. Die Vollansicht eines Blog-Eintrags kann durch Klicken auf den Titel eines Blog-Eintrags in der Liste oder durch einen direkten Aufruf eines Eintrags über seine ID erreicht werden. Die Ansicht des ersten Eintrags unter der URL lautet http://gpblog/show_entry/1.
8.3.10 Gebietsabhängiges Datum
Als Vorbereitung auf das folgende Kapitel, in dem sämtliche Texte übersetzbar gemacht werden, soll sich das Datumsformat schon jetzt an der Ausgabesprache orientieren. Dafür definieren wir als Erstes eine neue Konfigurationsoption in der Datei site.ini, die das Gebiet definiert, in dem sich der Blog-Autor befindet.
# Your locale locale=de_DE
Listing 8.14 Locale in der Datei site.ini setzen
Die verfügbaren Locales kann man sich unter Unix durch `locale -a` auf der Konsole anzeigen lassen, auf deutschen Systemen sollte de_DE meistens verfügbar sein.
Als Nächstes ändern wir den Aufruf der Funktion in den Templates. Anstelle von date_format_timestamp() verwenden wir nun gp_show_date() mit einem anderen Format-String. Da wir in der selbst definierten Funktion die PHP-Funktion strftime() verwenden werden, akzeptiert unsere Template-Funktion die gleichen Format-Strings. Der entsprechende Bereich des Templates für die Liste der Blog-Einträge gestaltet sich damit, wie es das folgende Listing zeigt. Beachten sie besonders den fett gedruckten Bereich mit dem Aufruf der noch zu schreibenden Funktion.
<h3>
<a href="{$base}show_entry/{$entry->id}">
{$entry->title}
</a>
</h3>
<h4>{gp_show_date('%A, %d. %B %Y – %H:%M', $entry->date)}</h4>
<p>
{raw $entry->body}
</p>Listing 8.15 Verwendung von gp_show_date() im Template
Selbst geschriebene Template-Funktionen lassen sich in Klassen gruppieren, die das Interface ezcTemplateCustomFunction implementieren. Die neue Klasse nennen wir gpBlogCustomFunctions. Sie findet sich in der Datei classes/ template_functions.php. Nachdem sie zur autoload-Datei hinzugefügt wurde, kann mit der Implementierung der Klasse begonnen werden.
class gpBlogCustomFunctions implements ezcTemplateCustomFunction
{
/**
* Return function definition for function name
*
* @param string $name
* @return ezcTemplateCustomFunctionDefinition
*/
public static function getCustomFunctionDefinition( $name )
{
switch ( $name )
{
case 'gp_show_date':
$def = new ezcTemplateCustomFunctionDefinition();
$def->class = __CLASS__;
$def->method = 'showDate';
return $def;
}
return false;
}
// ...
}Listing 8.16 Definition einer Template-Funktion
Das Interface forciert die Implementierung der Methode getCustomFunctionDefinition(), die ein Objekt der Klasse ezcTemplateCustomFunctionDefinition für alle implementierten Funktionen zurückgeben muss. Dazu werden die bei der Template-Engine registrierten Erweiterungen bei unbekannten Funktionen befragt, ob sie diese Funktion bereitstellen, und im Erfolgsfall die hier referenzierte Funktion direkt aufgerufen. Falls diese Extension die angefragte Funktion nicht bereitstellt, gibt die Methode false zurück und die nächsten registrierten Erweiterungen werden befragt. Falls aus einem Template heraus versucht wird, eine unbekannte Funktion aufzurufen, wird eine Exception der Klasse ezcTemplateRuntimeException geworfen.
In dem ezcTemplateCustomFunctionDefinition-Objekt werden die Klasse und Methode spezifiziert, an die ein Aufruf der selbst definierten Template-Funktion weitergeleitet werden soll. In diesem Beispiel soll die Methode showDate() auf der gleichen Klasse verwendet werden.
public static function showDate( $format, $timestamp = null )
{
// Set locales
$configuration = ezcConfigurationManager::getInstance();
$locale = $configuration->
getSetting( 'site', 'installation', 'locale' );
setlocale( LC_TIME, $locale );
return strftime( $format, $timestamp );
}Listing 8.17 Lokalisiertes Datum ausgeben
In der statischen Methode wird das in der ini-Datei spezifizierte Locale über die in Kapitel 5, »Konfiguration«, näher beschriebene Configuration-Komponente abgefragt. Mit diesem Wert werden die Locales für die Formatierung von Datums- und Zeitangaben gesetzt. Die PHP-Funktion strftime() gibt nun abhängig vom Format und der übergebenen Zeit eine gebietsabhängige Zeichenkette mit der Zeit zurück.
Zum Abschluss muss die Erweiterung bei der Template-Komponente registriert werden. Dazu wird erneut die Methode display(), in der die Template-Komponente initialisiert wurde, modifiziert.
$template = new ezcTemplate();
$config = ezcTemplateConfiguration::getInstance();
$config->templatePath = dirname( __FILE__ ) . '/../templates';
$config->compilePath = dirname( __FILE__ ) . '/../templates_compiled';
$config->context = new ezcTemplateXhtmlContext();
$config->addExtension( 'gpBlogCustomFunctions' );Listing 8.18 Eigene Extension verwenden
Die bisherige Template-Konfiguration wird durch das Hinzufügen der gerade erzeugten Klasse gpBlogCustomFunctions über die Methode addExtension() auf dem Objekt der Klasse ezcTemplateConfiguration erweitert. Damit ist die selbst geschriebene Template-Funktion verfügbar und die Datumsangaben im Blog erscheinen in der konfigurierten Sprache.
Abbildung 8.2 Anzeige eines Blog-Eintrags mit Kommentaren
