Diskussion:Template-Engine

message: 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)
replies: text: 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)
thread_title:  Overhead 

message: 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)
thread_title:  Sinn und Zweck 

message: 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)
replies: text: 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)
thread_title:  Andere Engines 

message: <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)
thread_title:  Kurzes Beispiel (Quellcode): ist speziell, behauptet aber allgemeingültig zu sein 

message: ... 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)
thread_title:  "Template Engines und Programmiersprachen" überflüssig 

message: 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)
thread_title:  Aufgeräumt 

message: * 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)
thread_title:  unvollständig und einseitig 

message: 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)
replies: text: "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)
thread_title:  Verdeutschung "Template" 

message: 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)
thread_title:  textuelle Ausgabe ev. zu eng 

message: 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)
thread_title:  Umstrukturierung 

message: – GiftBot (Diskussion) 17:57, 23. Dez. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekte Weblinks 

message: 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)
thread_title:  Hinweis auf C++ Klassentemplates