nicht angemeldet
Template-Engine
Hallo,
ich wollte mal in die Runde fragen, ob ihr bei Euren Projekten Template-Engines[*] benutzt.
Wenn ja, welche benutzt Ihr?
Was sind, eurer Meinung nach, die Vorzüge an der Engine, die ihr benutzt?
Was sind, eurer Meinung nach, die Nachteile an anderen Engines?
Danke im Voraus.
Grüße
- Steffen
*) PHP als Template-Engine bitte mal außen vor lassen.
-
Tach!
ich wollte mal in die Runde fragen, ob ihr bei Euren Projekten Template-Engines[*] benutzt.
Nein, aber ich würde, wenn ihr Einsatz sinnvoll wäre. Das wäre, wenn andere am Aussehen arbeiten und sich nicht mit der Verwendung von PHP nebst ein paar Helferlein anfreunden können, oder ein übergeordneter Zwang besteht. Vor der Verwendung von Kontrollstrukturen (Schleifen und bedingte Ausgaben) und dem Wissen, wann was maskiert werden muss und wann nicht, werden sie sich auch mit separater Template-Engine nicht drücken können. Ansonsten kann ja gleich ein Programmierer eine statische Vorlage nehmen und die variablen Teile unter Verwendung von PHP-Code einfügen.
Was sind, eurer Meinung nach, die Nachteile an anderen Engines?
Sie bringen eine Komplexitätserhöhung ins Projekt, wieder etwas, das man warten und gegebenenfalls erst noch erlernen muss. Performance kann auch noch eine Rolle spielen.
dedlfix.
-
Wenn ja, welche benutzt Ihr?
Bei grösseren Projekten nutze ich Smarty3, bei kleineren gar keine, bzw. was kleines, selbstgezimmertes
Was sind, eurer Meinung nach, die Vorzüge an der Engine, die ihr benutzt?
Wird stetig weiterentwickelt, läuft auf jedem Webspace, der PHP unterstützt und ist gut erweiterbar.
Die Syntax ist recht einfach, dadurch können auch nicht-Programmierer die Templates anpassen, wenn sie HTML und CSS können und sich etwas in die Smarty-Syntax einlesen.Was sind, eurer Meinung nach, die Nachteile an anderen Engines?
Bei anderen, die ich probiert hab, hatte ich immer PHP-Code im Template (hab aber nicht viele probiert). Ich bin der Meinung, PHP-Code hat im Template nichts verloren.
*) PHP als Template-Engine bitte mal außen vor lassen.
PHP ist für mich keine Template-Engine sondern eine Programmiersprache. Ich hab nie verstanden, wieso mancher PHP als Template-Engine bezeichnet.
--
42-
Ich hab nie verstanden, wieso mancher PHP als Template-Engine bezeichnet.
Weil sowas geht:
<?php ## filename: do_all.php $titel="Alles ganz toll!";<?php ## filename: template_all.php ?><!DOCTYPE html> <html> <head> <title><?php echo htmlspecialchars($titel)</title> </head> <body> <h1><?php echo htmlspecialchars($titel)</h1> </body> </html>[code lang=php]<?php
filename: index.php
require_once 'do_all.php';
require_once 'template_all.php';
?>Schön ist das nicht ... geht aber.
Jörg Reinholz
-
Mahlzeit,
Schön ist das nicht ... geht aber.
Klar geht sowas. Aber da der Code nicht vom Design getrennt wird, weigere ich mich, es als Template-Engine zu akzeptieren ;)
--
42
-
-
-
Twig fande ich ganz angenehm, hat mich etwas an Djangos Template Sprache erinnert. PHP kann man aber doch auch wundervoll einfach so als Template-Sprache nutzen. Ob der Layouter nun TWIG-Syntax lernt, oder ein bisschen rudimentäres PHP, ist egal. Gut, der Ansatz ist etwas anders.
Humorlose Grüße
-
ach so, hier noch der Link zu Twig auf Wikipedia, falls von Interesse
-
Mahlzeit,
Ob der Layouter nun TWIG-Syntax lernt, oder ein bisschen rudimentäres PHP, ist egal.
Also ist es für dich egal, ob ein Layouter per PHP Sicherheitslücken ins System reissen kann, weil er eben kaum PHP kann oder nicht?
--
42-
Hallo,
Ob der Layouter nun TWIG-Syntax lernt, oder ein bisschen rudimentäres PHP, ist egal.
Also ist es für dich egal, ob ein Layouter per PHP Sicherheitslücken ins System reissen kann, weil er eben kaum PHP kann oder nicht?
das ist sicherlich ein Punkt, der zu beachten ist. Allerdings sollte man vielleicht nicht jeden Deppen ans System lassen und zweitens entsprechende Template-Variablen zur Verfügung stellen, die er nur noch per echo auszugeben hat. Alle Logik passiert sowieso nicht im Template (wobei wir wieder bei strikter Trennung von Ausgabe und Logik wären, ich weiß, ich weiß). Deshalb würde ich im Falle von PHP wohl TWIG bevorzugen, vorausgesetzt, das Projekt ist groß genug.
-
Allerdings sollte man vielleicht nicht jeden Deppen ans System lassen
Das ist das Problem. Ein Designer/Layouter ist idR programmiertechnisch ein Depp. Ebenso wie die meisten Programmierer designtechnisch Deppen sind.
und zweitens entsprechende Template-Variablen zur Verfügung stellen, die er nur noch per echo auszugeben hat.
Dann hast du aber eine API und somit muss eine API und nicht "nur" PHP gelernt werden. Dann geht auch gleich ne Template-Engine.
Ausserdem besteht ja weiterhin die Möglichkeit, schädlichen Code zu schreiben.Man darf Dummheit/Kurzsicht/Unwissen nie unterschätzen.Ich versteh deinen Standpunkt schon, bin aber grundsätzlich anderer Meinung ;)
--
42-
und zweitens entsprechende Template-Variablen zur Verfügung stellen, die er nur noch per echo auszugeben hat.
Dann hast du aber eine API und somit muss eine API und nicht "nur" PHP gelernt werden. Dann geht auch gleich ne Template-Engine.
na ja, naaa ja. API ist hier wohl etwas übertrieben. Man stellt ihm halt einen Katalog aus Variablen zur Verfügung, die "er" dann einbindet:
$tmpVar["contact_form"], $tmpVar["user_list"] etc.
das müsste doch lern- und verstehbar sein. Ich meine, wer HTML und CSS kann, wird das ja wohl auch noch hinbekommen.
Ausserdem besteht ja weiterhin die Möglichkeit, schädlichen Code zu schreiben.Man darf Dummheit/Kurzsicht/Unwissen nie unterschätzen.
DAS ist allerdings war. Eventuell müsste man das Template vorher noch "scannen" in irgendeiner Form.
Ja, auch ich verstehe deinen Standpunkt, der nicht von der Hand zu weisen ist. PHP ist nun mal eine Programmiersprache.
-
wahr meinte ich.
-
Mahlzeit,
DAS ist allerdings war. Eventuell müsste man das Template vorher noch "scannen" in irgendeiner Form.
Das wäre eine Möglichkeit, ich bezweifel aber, dass dann die Performance besser ist als bei einer Template-Engine.
Oder haben wir dann schon eine Template-Engine, weil ja in gewisser Weise geparst werden muss? Wohl eine Streitfrage.Hast du mal Versuche angestellt, inwieweit es die Performance beeinflusst, wenn ein Template vor Ausführung geprüft wird? Ich hab keine Erfahrung damit.
Evtl. kann man ja ein Template nur nach einer Änderung prüfen und beim normalen Durchlauf dann einfach ausführen. Der Ansatz ist sicher durchführbar, hab dahingehend noch nie was ausprobiert.
--
42-
Hallo,
DAS ist allerdings war. Eventuell müsste man das Template vorher noch "scannen" in irgendeiner Form.
Das wäre eine Möglichkeit, ich bezweifel aber, dass dann die Performance besser ist als bei einer Template-Engine.
Oder haben wir dann schon eine Template-Engine, weil ja in gewisser Weise geparst werden muss? Wohl eine Streitfrage.Template-Engine... komischer Begriff eigentlich.
Hast du mal Versuche angestellt, inwieweit es die Performance beeinflusst, wenn ein Template vor Ausführung geprüft wird? Ich hab keine Erfahrung damit.
Nein, ich vertraue unseren Codern blind.
Evtl. kann man ja ein Template nur nach einer Änderung prüfen und beim normalen Durchlauf dann einfach ausführen. Der Ansatz ist sicher durchführbar, hab dahingehend noch nie was ausprobiert.
Würde gehen, aber etwas aufwändig, wie ich meine. Dann lieber gleich Twig.
-
Meine Herren!
Nein, ich vertraue unseren Codern blind.
Soviel Selbstvertrauen kann ich nicht mal aufbringen.
-
Mahlzeit,
Nein, ich vertraue unseren Codern blind.
Und das ohne Humor? Das dürfte zum weinen sein.
Allerdings sind Coder ja keine Layouter sondern Programmierer.--
42-
Tach!
Nein, ich vertraue unseren Codern blind.
Und das ohne Humor? Das dürfte zum weinen sein.
Allerdings sind Coder ja keine Layouter sondern Programmierer.Manchmal habe selbst ich einen Hang zum Humorösen... nein, ganz ehrlich, beruflich machen wir fast nicht im Web und wenn dann mal doch, dann sind die Coder, wie du schon richtig erkannt hast, Programmierer. Wie gesagt, gegen Sabotage kann ich allerdings dann auch nichts machen.
Es ist zum Weinen, richtig.
Humorlose Grüße
-
-
-
-
-
-
Tach!
das ist sicherlich ein Punkt, der zu beachten ist. Allerdings sollte man vielleicht nicht jeden Deppen ans System lassen und zweitens entsprechende Template-Variablen zur Verfügung stellen, die er nur noch per echo auszugeben hat. Alle Logik passiert sowieso nicht im Template (wobei wir wieder bei strikter Trennung von Ausgabe und Logik wären, ich weiß, ich weiß).
Das würde ich nicht als allgemeine Regel propagieren. Es gibt Logik, die für den eigentlich zu lösenden Anwendungsfall benötigt wird, die Geschäftslogik. Und es gibt Logik, die für die Ausgabe benötigt wird. Als Beispiel sei die Frage genommen, ob es Fehlermeldungen auszugeben gibt oder nicht. Die Antwort darauf führt zu unterschiedlichem HTML. Ohne Meldungen braucht es gar nichts, mit Meldungen braucht es einen Block mit Überschrift und einer Liste mit den Meldungstexten - oder irgendetwas ähnliches. Wenn du die Logik aus den Templates raushalten willst, muss du selbst das entsprechende HTML schreiben, es in eine Variable packen, die dann nur noch auszugeben ist. Ohne Fehler ist sie ein Leerstring, mit Fehlern das HTML. Und das darf dann auch nicht noch einmal vom Template maskiert werden. Du musst also schon in der dem Template vorgeschalteten Ausgabelogik wissen, was der Ausgabekontext ist, um korrekten Code zu liefern. Zudem kann nun der Designer nichts mehr an dem Code designen.
Eine Alternative dazu ist, einige Logik-Elemente (in dem Fall if und for(each)) in die Template-Sprache aufzunehmen. Das aber widerspräche dem strikten Trennungsprinzip. Noch eine Möglichkeit wäre, ein System mit Blöcken zu verwenden, deren Anzeige von der vorgelagerten Logik gesteuert wird. Man muss dann aber als Programmierer gegebenenfalls enger mit dem Designer zusammenarbeiten, weil der ja die Schachtlung von Blöcken ändern kann und dann eventuelle Änderungen an der Logik zu vollziehen sind. Wenn die Logik in der Template-Syntax selbst verankert ist (und der Designer sie anzuwenden versteht), dann kann er selbst die zu seinen Änderungen passende Logik nachziehen, und man muss als Programmierer nur die Rohdaten zur Verfügung stellen.
Zusammengefasst: Eine Trennung nach Ausgabe und Logik halte ich nicht für erstrebenswert, wohl aber eine Trennung nach Geschäftslogik und Ausgabelogik.
dedlfix.
-
Hallo,
Zusammengefasst: Eine Trennung nach Ausgabe und Logik halte ich nicht für erstrebenswert, wohl aber eine Trennung nach Geschäftslogik und Ausgabelogik.
unterschreibe ich so.
Humorlose Grüße
-
-
-
-
-
ich wollte mal in die Runde fragen, ob ihr bei Euren Projekten Template-Engines[*] benutzt.
da ich hauptsächlich Perl mache und kein PHP, antworte ich mal nur auf diese Frage. Welche Engine ich benutze, ist dann wohl uninteressant für dich =)
Ich benutze praktisch immer ein Template-System. Nicht nur, wenn Nicht-ProgrammiererInnen an den Templates arbeiten.
Es ist für mich eine sinnvolle Trennung von Code und Ausgabe, die mich davor bewahrt, zuviel Logik im Template unterzubringen. Daher benutze ich auch ungerne Template-Systeme, bei denen man Perl-Code direkt benutzt. -
Meine Herren,
ich wollte mal in die Runde fragen, ob ihr bei Euren Projekten Template-Engines[*] benutzt.
Wenn ja, welche benutzt Ihr?
Da ich beruflich viel mit Typo3 am Hut habe, könnte ich prompt mit TypoScript oder TemplaVoila antworten. Empfehlen würde ich sie allerdings nicht, zumal mir auch keine andere Umgebung als Typo3 bekannt ist, die darauf setzt. Außerdem missfallen mir viele Design-Patterns, die diese Namensträger umsetzen oder eben nicht umsetzen.
Persönlich stehe ich auf logic-less Template-Engines wie Mustache oder (darauf aufbauend) Handlebars. Meine Erfahrungen damit sind aber mehr hobbyartiger Natur und vor allem auf Frontend-Templating beschränkt, da gibt es natürlich ganz andere Voraussetzungen (z.B. Data-Binding).
-
Da ich beruflich viel mit Typo3 am Hut habe,
offenbar nicht genug ;)
könnte ich prompt mit TypoScript
TypoScript ist keine Template-Engine, es ist die Konfigurationssprache für TYPO3. Die Template-Engine von TYPO3 ist derzeit "Fluid" - die lässt sich selbstverständlich auch mit TypoScript konfigurieren.
oder TemplaVoila antworten. Empfehlen würde ich sie allerdings nicht, zumal mir auch keine andere Umgebung als Typo3 bekannt ist, die darauf setzt.
Wer damit arbeitet ist wohl selbst schuld ;) TemplaVoila führt schnell zum Erfolg, automatisiert aber weitgehend und produziert Mistcode.
Außerdem missfallen mir viele Design-Patterns, die diese Namensträger umsetzen oder eben nicht umsetzen.
Das ganze Design-Patterns zu nennen ist ziemlich gewagt - es ist schlichtweg eine Frechheit und absolut nicht nachvollziehbar, warum TemplaVoila im professionellen Umfeld überhaupt verwendet wird.
-
Meine Herren,
Da ich beruflich viel mit Typo3 am Hut habe,
offenbar nicht genug ;)
Das möchte ich nicht bestreiten. Ein Jahr mit rund 10 Wochenstunden Typo3 habe gerade mal auf dem Buckel, für so ein Teufels-CMS noch lange nicht ausreichend.
Das ganze Design-Patterns zu nennen ist ziemlich gewagt - es ist schlichtweg eine Frechheit und absolut nicht nachvollziehbar, warum TemplaVoila im professionellen Umfeld überhaupt verwendet wird.
Weil unsere Designer, die nun mal keine Programmierer sind, damit umzugehen wissen und achtbare Ergebnisse hervorbringen.
--
Hey Girl,
i wish you were asynchronous, so you'd give me a callback.
-
-
-
hi,
Was sind, eurer Meinung nach, die Vorzüge an der Engine, die ihr benutzt?
Eine stricte Trennung zwischen Layout und Programmlogik, ausgezeichnete Performance, kleine Kontrollstrukturen, Loops, saubere Trennung der Platzhalter-Geltungsbereiche (Diese Trennung ist wichtig, denn es darf nicht passieren, dass mit Werten, welche in der Konfiguration gesetzt sind, Werte überschrieben werden für die der Programmcode zuständig ist. Andererseits muss es möglich sein, dass der Programmcode beispielsweise den Titel einer Seite ändert. EAV (Entity Attribute Value) ist hier das richtige Entwurfsmuster.).
Im Template selbst darf es natürlich nicht möglich sein, dass vermittels der Templatesprache eigenmächtig irgendwelche Variablen geändert werden dürfen, nicht einmal die eigenen Platzhalter, die so gesehen gar keine Variablen sind. Im Template etwa auf ein $_POST zugreifen zu können, das ist aus meiner Sicht ein absolutes No go.
Kleine Kontrollstrukturen: Wenn es sich in der Enticklung abzeichnet, dass das Template einem Programmcode immer ähnlicher wird, hilft nur eines: Das Template per Programmlogik austauschen.
Andererseits gibt es sehr oft Situationen im Programmcode, wo Templates angebracht sind, z.B. verwende ich als Ersatz für
sprintf()sehr oft meine eigene TTE, da heißen die Platzahlter nicht %s sondern haben Namen, die ich selbst vergeben kann und die ein bischen aussagekräftiger sind ;)Also, ich rede hier von _meiner_ TTEngine (Perl). Was PHP betrifft:
Da habe ich eine Zeitlang Twig benutzt. Es wäre noch zu prüfen, ob o.g. Features passen, wahrscheinlich eher nicht ;)
Horst Heitzer