Diskussion:Template Engine
aus Wikipedia, der freien Enzyklopädie
Im Artikel steht, das es Templating Systeme für viele Sprachen gibt, aber immer wenn es um Programmcode geht, steht da PHP davor?!? Ich habe das mal korrigiert. --217.187.85.111 09:37, 28. Dez 2005 (CET)
Das deutsche Wikipedia - im Gegensatz zum englischen Wikipedia - scheint Artikel zu anderen (verbreiteten) Template Engines zu verbieten. Zumindest ist ein Löschantrag gegen "vlibTemplate" erfolgreich verlaufen. Da Smarty aber seine Berechtigung zu haben scheint, werde ich keine weiteren Template Engines vorstellen, sondern nur extern verlinken. Demnach sollte auch die Reihenfolge der PHP-Template-Engines nicht geändert werden, weil Smarty von den Administratoren (und php.net) wohl bevorzugt wird. --ClausVB 16:36, 17. Jan 2006 (CET)
Savant ist keine "richtige" PHP-Template-Engine, weil sie keine eigenen Markup Tags besitzt (Erweiterung ist möglich) und kein WYSIWYG unterstützt. Jede "richtige" PHP-Template-Engine besitzt diese beiden Features. Das gilt für die Templates vom CMS Imperia (Unternehmen in Hürth), als auch Typo3. Trotzdem sollten diese Klassen hier aufgeführt werden. Sobald wir 2 oder mehr zusammen haben, mache ich (oder Ihr) dafür eine eigene Überschrift auf. Ich habe den Artikel so abgeändert, das Savant als Ergänzung zum dargestellten PHP-Code dient. -- ClausVB 02:37, 23. Jan 2006 (CET)
- smarty ist eine denkbar schlechte template-engine es erfüllt den zweck nicht ordentlich und hat zu große overhead (geschrieben von 84.180.231.166)
- Eine Frage: Was hat eine Template-Engine und WYSIWYG gemeinsam? Ausser das man beides in PHP Programmieren kann, sehe ich da keinen Zusammenhang. Eine PHP-T-Engine muss kein WYSIWYG besitzen, denn Templates muss man ja nicht zwingend in einem vorgegeben Editor schreiben. Und ausserdem müssen eigene Tags ja auch nicht vorhanden sein, weil wenn man wichtige, gute Tags von anderen Engines nimmt, sind das keine eigenen, wäre aber der beste Grund, umzusteigen. --Dear, _linx_
Inhaltsverzeichnis |
[Bearbeiten] Overhead
Im Artikel steht als Nachteil "[Templates] erzeugen immer zusätzlichen Overhead.". Das halte ich erstmal für ungenau. Overhead=Zusatzaufwand, im Bezug auf was entsteht da zusätzlischer Aufwand? Wenn der Overhead, der durchs Parsen entsteht, gemeint ist, so stimmt das nicht prinzipiell, da es Template Engines gibt, die das Template einmal analysieren, und daraus ganz normalen Programmcode generieren. (Ich meine, z.B. Smarty täte das).
- Der Begriff "Overhead" ist im Wikipedia unter anderem so definiert: "in der elektronischen Datenübertragung (EDV) Daten, die nicht primär zu den Nutzdaten zählen, sondern als Zusatzinformation zur Übermittlung oder Speicherung benötigt werden, siehe Overhead (EDV)". Bei PHP- und Perl Template Engines, die für Webseiten genutzt werden, betrifft der Overhead zusätzliche RAM-Nutzung (Speichernutzung für alle INCLUDES) und zusätzliche Zeit für das Parsen. Das lässt sich (je nach Anwendung und Server) sogar messen und liegt mitunter im drei- bis vierstelligem Bereich (Millisekunden). Die von Dir zitierte Aussage ist nicht nur richtig, sondern auch ziemlich präzise, wenn man weiß, was Overhead in der EDV bedeutet. IMHO soll der Artikel einen Überblick über Template Engines geben und nicht wissenschaftlich und detail-verliebt sein. Außerdem bin ich nicht qualifiziert über den Overhead von ASP oder Java zu sprechen, also kann ich auch kein zusätzliches Kapitel "Overhead" schreiben. --ClausVB 12:00, 6. Sep 2006 (CEST)
[Bearbeiten] Sinn und Zweck
Vielleicht sollte man den Sinn und Zweck einer Template-Engine erklären. Es wird erwähnt, sie diene dazu Programmcode und Design zu trennen. Das stimmt so nicht. Bei einer Template-Engine geht es mehr darum, Design (in der Regel HTML) und Code auf möglichst einfache Weise zusammenzubringen. Ohne eine Template-Engine wäre ein Programmierer gezwungen (ausser er programmiert in PHP) den kompletten HTML-Code einer Webseite in sein Programm einzubetten, wenn die Seite dynamische Elemente enthalten soll. Das ist selbst bei einer sehr einfachen Seite, die nur die Uhrzeit als dynamische Information ausgibt, sehr aufwendig, da man z.B. viele Zeichen im HTML-Code escapen müsste, damit sie die jeweilige Programmiersprache dann als gültigen String akzeptiert und das Programm fast ausschliesslich aus print-Anweisungen für Konstanten bestehen würde.
Anstatt also sehr viel HTML in wenig Code einzubetten erlauben es Template-Engines wenig Code in viel HTML einzubetten, was das Programmieren deutlich vereinfacht, aber eine Trennung von Code und HTML ist das nicht.
Das MVC-Konzept wiederum schlägt eine bestimmte Aufteilung eines Programms in verschiedene Aufgabenbereiche vor. Aber auch hier geht es nicht um die Trennung von Design und Code: Model, View und Controller ist alles Programmcode, nur die Funktion der Programmteile ist unterschiedlich.
Wenn man nach dem MVC-Konzept Webanwendungen programmiert, dann benötigt man dafür jedoch keine Template-Engine. Allerdings erleichtert deren Verwendung die Arbeit ungemein (s.o.), vor allem wenn Nicht-Programmierer die HTML-Seiten entwerfen.
Um es noch deutlicher zu machen: nach dem MVC-Konzept programmiert man auch Desktop-Anwendungen, und dort setzt sich der View aus den Programmteilen zusammen, die die GUI entstehen lassen = 100% Programmcode. Umso weniger überraschend ist es dann auch, dass viele Template-Engines eine eigene Programmiersprache haben, die für den angegebenen Zweck die nötigsten Funktionen oder auch deutlich mehr bereitstellt.
Wie oben bereits angedeutet gibt es bei den Programmiersprachen Ausnahmen: z.B. PHP. PHP erlaubt es bereits von Hause aus, Programmcode in HTML einzubetten. Folglich benötigt man in PHP auch keine Template-Engine, die ja dem selben Zweck dient. Um nach dem MVC-Konzept zu programmieren oder um zumindest den View von der restlichen Logik zu trennen, reicht es aus, dass man nur das nötigste in die HTML-Seiten hineinprogrammiert und sich soweit wie möglich zurückhält. D.h. viel mehr als einige <?php echo $xxx; ?> sollte nicht hinein. Oder anders ausgedrückt: In PHP lassen sich Templates direkt in PHP formulieren.
Warum gibt es Template Engines für PHP aber dennoch? Da es in PHP schon immer sehr leicht war, HTML und Programm zu mischen, wurde auch entsprechend programmiert und aus einem netten kleinen Programm wurde schnell ein unwartbares Monster. Also wagte man einen Blick über den Tellerrand zu den anderen Programmiersprachen wie z.B. Java oder Perl. Dort verwendete man Templates getrennt von den restlichen Programmen. Und Template-Engines. Aber so richtig begriffen hat man auf der PHP-Seite nicht, warum Template-Engines verwendet wurden, denn das Problem, das sie lösen, ist PHP-Programmieren unbekannt und folglich wurden Templates und Template-Engines fest miteinander verknüpft. Zudem kam der spartanische Sprachumfang den Erwartungen auch sehr entgegen und es setzte sich der Gedanke durch, Sinn und Zweck einer Template-Engine sei es, dem Programmierer Mässigung geradezu aufzuzwingen. Dabei erklärt sich der geringe Funktionsumfang wohl eher damit, dass die ersten Entwickler von Template-Engines für z.B. Perl wohl kaum mal so eben eine komplette Programmiersprache für diesen Zweck aus dem Ärmel schütteln konnten bzw. den riesigen Aufwand für den angedachten Zweck scheuten.
Hätte man auf der PHP-Seite den Blick noch weiter über den Tellerrand schweifen lassen, dann hätte man z.B. JSP oder auch ePerl entdecken können. Das Problem der meisten Template-Engines ist nämlich, dass man eine weitere Sprache erlernen muss. Die ist bei den richtig guten Engines recht umfangreich. Der Blick von der anderen Seite über den Tellerrand fiel dann wohl auf PHP.
Template-Engines sind letztlich eine Krücke und folglich werden sie von neuen Technologien wieder zurückgedrängt, wie z.B. JSP. Aber auch in Ruby on Rails werden die Views z.B. in eRuby programmiert, d.h. man verwendet die Sprache, die man auch sonst verwendet. So kommt man nun dort so langsam an, wo PHP schon immer war.
Ich finde, der Artikel beleuchtet das Thema zu sehr von der PHP-Seite her und transportiert folglich auch die dort üblichen Missverständnisse.
[Bearbeiten] Andere Engines
Eine der wichtigsten Template-Engines fehlt: ZPT - Zope Page Templates. Sie existiert zwar im wesentlichen nur für Zope, aber das Konzept ist absolut erwähnenswert. Das erkennt man auch daran, dass es etliche Umsetzungen in andere Sprachen gibt, wie z.B. PHPtal, JavaZPT, PETAL (Perl).
Eine anderes wichtiges System für einen Lexikoneintrag ist natürlich auch das Template Toolkit von Perl.
- Eine gute Nachricht: Es gibt jetzt Artikel für ZPT sowie die verwendeten Technologien TAL, METAL und TALES, die außer von Zope mindestens noch von Roundup (Bugtracker) verwendet werden. Ich habe den hiesigen Artikel soeben erst entdeckt, deshalb ist es noch nicht eingebaut. Die Implementierungen in anderen Sprachen waren/sind mir nicht bekannt (schade, daß Du nicht signiert hast, ich hätte Dich gern nach Links gefragt); es gibt mit SimpleTAL mindestens eine weitere Python-Implementierung (warum auch immer, vermutlich aus Lizenzgründen).
- Verglichen mit dem sauberen Ansatz von TAL und Consorten ist die JSP-Praxis IMO nur als Schmerz im Arsch zu betrachten. --Tobias 19:34, 10. Apr. 2007 (CEST)
- Habe alle gefunden (und noch ein paar mehr, die vom Zope-Wiki verlinkt waren; zwei Java-Implementierungen weisen darauf hin, daß JSP auch Java-Leuten nicht reicht) und auf der Seite für die Template Attribute Language eingebaut. Danke für den anonymen Hinweis ;-) --Tobias 20:57, 10. Apr. 2007 (CEST)
[Bearbeiten] Kurzes Beispiel (Quellcode): ist speziell, behauptet aber allgemeingültig zu sein
<schnipp...>
- Um eine Template Engine zu verwenden, muss man zwei Dateien erstellen
- template.htm
- script.* (z. B. script.php, script.pl, script.asp, etc.)
- die auch in verschiedenen Verzeichnissen abgespeichert werden können.
- Das Template könnte so aussehen:
<body>
<p>{NAME}</p>
</body>
- Und so könnte dann der PHP-Code aussehen:
$template->assign('NAME', 'Erika Mustermann');
Das Ergebnis:
<body> <p>Erika Mustermann</p> </body>
- Nicht jede Template Engine benutzt Methoden wie "assign". Namen wie "setvar" oder "merge" sind ebenso möglich. Detaillierte Beispiele kann man unter vlibTemplate und Smarty (siehe Weblinks) ansehen.
<...schnapp>
Ob die Methode jetzt assign, setvar oder merge heißt, ist m. E. uninteressant. In ZPT sind die Templates Methoden, die auf ein Objekt angewendet werden und automatisch dessen Kontext (eigene und akquirierte Attribute, optional den Request...) verwenden. Überhaupt fehlt die Erwähnung der wirklich guten und modernen TAL/METAL/TALES-Architektur bisher völlig.
Ich habe den Abschnitt also hier mal gesichert; möglicherweise springt er ja über die Klinge... --Tobias 00:27, 11. Apr. 2007 (CEST)
[Bearbeiten] "Template Engines und Programmiersprachen" überflüssig
... weiter unten sind die sprachspezifischen Template Engines aufgeführt. Contemplate wird nicht näher erläutert (wie machen die das mit der Sprachunabhängigkeit, also der Unterstützung von ASP, PHP und Perl?
Lösche deshalb diesen Absatz. --Tobias 00:33, 11. Apr. 2007 (CEST)
[Bearbeiten] Aufgeräumt
Ich habe den ganzen Artikel mal etwas aufgeräumt und etwas kritischer gestaltet. Einige sehr subjektive Dinge habe ich komplett rausgeworfen. So sind z.B. die genannten Vorteile:
- Wenn man sich an die Benutzung von einer Template Engine gewöhnt hat, werden Webanwendungen in der Regel schneller entwickelt
- Die Wartbarkeit von beiden Teilen ist deutlich leichter
gar nicht belegbar, denn es fehlt ja die Vergleichsmöglichkeit. "Schneller entwickelt" als WAS? "Deutlich leichter" als WAS? Als Spaghetti-Code? Oder als Schweinebraten? Also insofern kann man das nicht stehen lassen.
Auch die eher eingeschränkte Perspektive aus Sicht von PHP-Programmierern ohne OOP-Kenntnisse habe ich versucht aufzulockern.
--Oimel 10:25, 9. Mai 2007 (CEST)
[Bearbeiten] unvollständig und einseitig
- in der Übersicht fehlen einige Beispiele für sprachunabhängige Template Engines, der Text ist aus Sicht von PHP-Programmieren geschrieben, zu viele Beispiele über PHP, allgemeinen Beispiele fehlen
- die Vor- und Nachteile sind nicht ausreichend begründet und zum Teil fachlich falsch ("Template Engines erzeugen Overhead")
--AlexLehm 22:00, 4. Juli 2007 (CEST)
