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_


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)
Es gibt von Apache Template Compiler für XSLT. Diese generieren sogenannte "translets". Ob Template Engines einen Overhead generieren ist eine nicht unwesentliche Frage. Ich denke der Overhead ist meist nicht in der eigentlichen Ausführung der Template zu finden, weil wenn diese kompiliert sind kann man zumindest annehmen dass es keinen Overhead durch die Interpretation gibt, sondern z.B. durch die Datenbeschaffung. Wenn z.B. die Template einen Push der Daten erwartet, dann kann es natürlich sein dass man unnötige Daten pushed. Das kann nur umgangen werden wenn die Template auch einen Daten Pop erlaubt. Aber ich denke viele Template Engine erlauben dies nicht. Ein XSLT dass ein XML als Input erwartet, und dann nur die Hälfte der Daten benutzt, generiert Overhead. Verglichen zu einer optimaleren Lösung. -- Janburse 10:45, 26. Okt. 2011 (CEST)

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.

Ich habe das Gefühl dass hier wirklich ein kleines Missverständnis im Artikel vorliegt. Das MVC Modell dient nicht nur der Darstellung sondern auch der Aktualisierung des Modells. Eine GUI Maske kann auch über Eingabefelder und Transaktionsknöpfe verfügen, und so zur Änderung des Modells führen. Bei Vorlagenprozessoren scheint mir das Hauptziel jedoch nur die Darstellung des Modells. D.h. Vorlagenprozessoren realisieren einen vereinfachten Spezialfall des MVC. Eine Grafik wie http://en.wikipedia.org/wiki/File:TempEngWeb017a.svg wäre hilfreich.
Aus dieser Vereinfachung ergibt sich auch eine andere Koppelung von Modell, Controller und View. z.B. findet man bei Vorlagenprozessoren selten dass Callbacks an das Modell geheftet werden, da die Annahme besteht dass das Modell read-locked bereitsteht. Dazu müssen oft Massnahmen wie Datawarehouse oder Historisierung getroffen werden. -- Janburse 11:11, 26. Okt. 2011 (CEST)

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)

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)

"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)

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)

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)

Verdeutschung "Template"

In der Praxis scheint der Begriff "Vorlage" verbreitet. Darum könnte man auch als Titel "Vorlagenprozessor" verwenden.

Man spricht auch häufig von "Fachdaten" anstatt nur Daten. Und die Platzhalter sind allgemein gesprochen im Design der "Fachdatenbezug".

-- Janburse 10:54, 26. Okt. 2011 (CEST)

"Schablone" wäre für C++ etwa passend, für die einfache Textersetzung ginge auch "Formular". "Vorlage" ist aber die deutsche Bezeichnung für "template" in C++. (nicht signierter Beitrag von 89.183.89.218 (Diskussion) 09:59, 17. Feb. 2015 (CET))

textuelle Ausgabe ev. zu eng

Textausgabe tönt sehr nach Bildschirmausgabe oder Webseite. Das Serienbrief zeigt aber schon dass auch andere Kannäle bedient werden können. Vorlagenprozessoren eignen sich auch dafür um E-mails, Fax, Druckdokumente, etc.. zu generieren. Vielleicht sollte das auch noch erwähnt werden.

Schliesslich können Vorlagenprozessoren auch für technische Kommunikation verwendet werden. So finden sie z.B. Anwendung bei der Generierung von SOAP Meldungen oder zur automatischen Generierung von Code bei MDA, etc..

-- Janburse 10:54, 26. Okt. 2011 (CEST)

Umstrukturierung

Ich bin dabei den Artikel (als Benutzerunterseite) grundlegend neuzuschreiben, da er sehr unübersichtlich ist und seit dem 8. Sep. 2011 auf der QS steht. Dafür benutze ich allerdings meinen den Benutzernamensraum, da ich nicht weiß, wie lange ich dafür brauchen werde. Außerdem möchte ich diesen Artikel nicht im unvollständigen Zustand lassen. Wenn ich soweit fertig bin, werde ich meine redigierte Version hierher übertragen. --Stoyno 18:09, 11. Feb. 2012 (CET)

Defekte Weblinks

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
  • Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks.
  • Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

– GiftBot (Diskussion) 17:57, 23. Dez. 2015 (CET)

Hinweis auf C++ Klassentemplates

Moin, ich halte den Vermerk auf C++ Klassentemplates "Klassen-Templates in der C++-Programmierung sind dagegen nicht mit Template-Engines vergleichbar, weil sie eine vom Datentyp unabhängige Programmierung ermöglichen und ganze Klassen generieren können" für überflüssig. Maximal ein kurzer Vermerk, dass Klassen-Templates etwas anderes sind, halte ich für gerechtfertigt. Anghenfil2 (Diskussion) 16:12, 15. Apr. 2018 (CEST)

Tapestry?

Tapestry ist keine Templateengine. Es verwendet Tags, das gilt aber für alles was man unter JEE macht, die sind dort überall verwendbar und keine Templateengine und vor allem kein Tapestry-eigenes Feature das nur Tapestry mitbringt. Insofern habe ich Tapestry von der Liste mal entfernt.

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Template-Engine&oldid=189144608“