Eigene ViewHelper
Nun soll das Blog-Beispiel noch ein wenig erweitert werden, indem ein ViewHelper für den Onlinedienst „Gravatar“ implementiert wird. Gravatar ordnet einer E-Mail-Adresse ein Avatarbild zu, sodass dieses Bild bei jedem Blogkommentar angezeigt wird, bei dem man seine E-Mail-Adresse angibt. Der ViewHelper muss also eine E-Mail-Adresse entgegen nehmen und soll dann folgende schematische Ausgabe erzeugen: „<img xsrc="http://gravatar.com/avatar/md5($email)" />“.
Um einen ViewHelper nutzen zu können, muss dieser zuerst importiert werden, bevor er im Template zur Verfügung steht. Der Import erfolgt mittels „{namespace blog=Tx_Blog_ViewHelpers}“. Nun können Sie ViewHelper unterhalb von „Tx_Blog_ViewHelpers“ aufrufen, indem Sie <blog:...>-Tags im Template nutzen.
Der Gravatar-ViewHelper soll über „<blog:gravatar>“ im Template angesteuert werden. Damit muss er in der Klasse „Tx_Fluid_ViewHelpers_GravatarViewHelper“ implementiert werden. Der Klassenname setzt sich zusammen aus dem Namespace, dem Namen des Tags (ohne Namespace-Prefix) und der Endung „ViewHelper“.
{namespace blog=Tx_Blog_ViewHelpers}
<blog:gravatar email="{post.author.email}" />
Listing 5
Gravatar-ViewHelper implemetieren
Jeder ViewHelper muss von „Tx_Fluid_Core_AbstractViewHelper“ erben. Außerdem muss er eine „render“-Methode besitzen, deren Rückgabewert in die Ausgabe eingefügt wird.
class Tx_Blog_ViewHelpers_GravatarViewHelper extends Tx_Fluid_Core_AbstractViewHelper {
public function render() {
return 'Hello World';
}
}
Listing 6
An der Stelle, an der im Template „<blog:gravatar />“ steht, wird nun „Hello World“ ausgegeben. Da wir die angegebene E-Mail-Adresse benötigen, müssen wir auf die Tag-Argumente zugreifen.
Argumente müssen registriert werden
Aus Sicherheitsgründen müssen alle Argumente mit Namen und Datentyp registriert werden – das Framework übernimmt dann die Überprüfung der Argumente. Die Registrierung der Argumente ist einfach:
/**
* @param string $email Email to look for
*/
public function render($email) {
...
}
Listing 7
Wie man sieht, werden alle Methodenargumente automatisch als Tag-Attribute registiert und stehen in der render()-Methode zur Verfügung. Ganz wichtig ist hier der Kommentarblock über dem Methodennamen, denn der Typ der Argumente (hier „string“) wird daraus entnommen. Die eigentliche Implementierung der Render-Methode ist anschließend ein Kinderspiel:
class Tx_Blog_ViewHelpers_GravatarViewHelper extends Tx_Fluid_Core_AbstractViewHelper {
/**
* @param string $email Email to look for
*/
public function render($email) {
return 'http://www.gravatar.com/avatar/' . md5(strtolower($email)) . '.jpg';
}
}
Listing 8
Es ist übrigens auch möglich, Argumente als optional zu definieren: Geben Sie dazu einfach Standardwerte an, wie Sie es von PHP kennen:
// Kommentarblock nicht vergessen!
public function render ($email, $imageSize = 'large') {...}
Listing 9
Fortgeschrittene Validierung
Durch die Angabe des Datentyps in „@param“ wird eine einfache Validierung durchgeführt. Leider ist diese hier nicht ausreichend. Der Nutzer kann beliebige Strings angeben, eigentlich sollen aber nur E-Mail-Adressen akzeptiert werden. Für solche Fälle gibt bietet Fluid erweiterte Validatoren, die durch den @validate-Tag verwendet werden können.
/**
* @param string $email Email of user
* @param string $imageSize Size of the image.
* @validate $email EmailAddressValidator
*/
public function render($email, $imageSize = 'large') {...}
Listing 10
Fazit
Als fester Bestandteil von TYPO3 4.3 und FLOW3 ermöglicht Fluid Entwicklern nicht nur flexibles und trotzdem einfaches Templating, sondern auch einen Einstieg in die Konzepte von FLOW3 und TYPO3 5.0.
Sebastian Kurfürst ist seit 2005 TYPO3-Kernentwickler und interessiert sich besonders für das Zusammenspiel von TYPO3 v4 und v5. Er studiert Informatik in Dresden und ist Mitgründer von sandstorm media (www.sandstorm-media.de).
9 Antworten
von Mirco 30.11.2009 (19:42Uhr) 1.
GENAIL! Danke für den Artikel. Das Prinzip dieser Templates, den ViewHelperl etc. kenne ich bereits vom ZendFramework, wo es grandios funktioniert. Ich hoffe doch stark, das auch der Rest vom T3-Core mit den nächsten Versionen auf MVC umgebaut wird (das soll ja mit FLOW kommen soweit ich weiß). Bleibt am Ball, danke :-)
von Steffen Müller 24.12.2009 (01:18Uhr) 2.
Die API scheint sich ein wenig verändert zu haben:
Statt
class Tx_Blog_ViewHelpers_GravatarViewHelper extends Tx_Fluid_Core_AbstractViewHelper {
muss es heißen:
class Tx_Blog_ViewHelpers_GravatarViewHelper extends Tx_Fluid_Core_ViewHelper_AbstractViewHelper {
von Sebastian Kurfürst 11.01.2010 (13:54Uhr) 3.
Hallo Steffen,
vielen Dank für die Korrektur, es wurden da noch ViewHelper in andere Positionen geschoben, da der Artikel weit vor Fluid 1.0 erschienen ist.
Jetzt, mit Fluid 1.0, erachten wir die öffentliche API als stabil an.
Viele Grüße,
Sebastian
von TYPO3: Meine ersten Erfahrungen mit Extb… 14.03.2010 (16:01Uhr) 4.
[...] holte ich mir in den Fachartikeln der t3n: Die Zukunft der Extensionentwicklung, von Jochen Rau Fluid: Templating leicht gemacht, von Sebastian Kurfürst Extension-Entwicklung mit Extbase und Fluid, von Patrick Lobacher und [...]
von cialis 22.06.2010 (11:09Uhr) 5.
Hallo und danke für den nützlichen Artikel. Genau das habe ich gesucht.
von TYPO3: Fluid – Templating Engine |… 03.09.2010 (21:43Uhr) 6.
[...] Artikel_t3n_Kurfürst [...]
von Die wahre Macht der neuen Template-Engin… 17.11.2010 (15:31Uhr) 7.
[...] t3n 16 [2] finden Sie einen ausführlichen Artikel zu Fluid, im Folgenden wird nur kurz auf die Syntax von [...]
von me@foo.bar 21.10.2011 (11:53Uhr) 8.
Das ist aber nicht richtig durchdacht, oder? Da habe ich ne Syntax für Variablen {} und dann noch "View-Helper", die sich an XML anlehnen. Woher weiß denn die Variablen-Syntax, in welchem Kontext sie angewendet wird? (Also [CDATA] oder Attribut).
Schon mal nen Blick auf TAL/Metal geworfen, wie man sowas richtig macht?
http://de.wikipedia.org/wiki/Zope_Page_Templates
von ak 11.02.2012 (16:30Uhr) 9.
oh man!
die jungs vom typo3-core team können es einfach nicht lassen. ich kann bis heute nicht nachvollziehen, wieso typoscript eingeführt wurde und ich weiss auch nicht warum jetzt wieder eine neue template sprache eingeführt werden soll... jaja, ich weiß. sicherheit, die bösen themer könnten ja sonst schlechten php code in die templates schreiben... jetzt mal ehrlich: auf grundlage von php noch eine extra script sprache obendrauf zu setzen (was wieder einen entsprechenden parser benötigt) ist FÜR MICH einfach schwachsinn und nicht nachvollziehbar... echt jetzt. was soll das?? welche gründe sprechen denn gegen die verwendung von php in templates???? ok - die deutsche korrektheit vielleicht oder das engere korsett für den themer... aber ansonsten müssen entwickler wieder eine neue syntax lernen, seiten müssen doppelt geparst werden (energie-kosten schon mal dabei bedacht?) und die so komplexe web-welt wird wieder um eine neue sprache erweitert... juhuu!!! ich weiß schon warum typo3 vor allem in deutschland angewendet wird... das passt einfach zum stock im arsch und zur korrektheit ;-)