XML-basierte Vorlagensprache gegen Smarty-Lexer

Question

Es gab viel Aufregung über Smarty 3 und seinen neuen Lexer und wie viel mehr Leistung er Ihnen als Vorlagendesigner geben würde, aber als es tatsächlich auf den Markt kam, war es eine echte Enttäuschung, wie langsam es war. Das Kompilieren einer Vorlage von Grund auf hat in Smarty 3 gut über eine Sekunde gedauert, während die gleiche Vorlage in Smarty 2 etwa eine halbe Sekunde gedauert hätte. Nicht gut.

Aber das hat mich zum Nachdenken gebracht, warum muss man einen vollwertigen Sprachparser in PHP implementieren, wenn es bereits Module wie DOMDocument, SimpleXML und ähnliches zur Verfügung hat?

Gibt es Template-Engines für PHP, die auf den XML-Erweiterungen und/oder DOMDocument basieren? Wenn ja, wie ist die Leistung? Wenn nicht, hat schon mal jemand versucht, eine zu schreiben?

Ein Nachteil, den ich sehe, ist, dass es wirklich nur für XML-basierte Formate wie XHTML und RSS nützlich wäre. Für die Erzeugung anderer Ausgaben (Nicht-XML-HTML, Klartext, CSS usw.) könnte es potenziell problematisch sein, obwohl man das wahrscheinlich mit CDATA-Blöcken umgehen könnte. Gibt es noch andere Implikationen für die Verwendung von XML/DOM für die Vorlagenverarbeitung, die ich nicht berücksichtigt habe?

Answer 1

Zu Ihrem Punkt über Smarty, soweit ich mich erinnern kann, verwendet Smarty "kompilierte Vorlagen", daher wird das von Ihnen erwähnte Leistungsproblem nur in der "Kompilierungsphase" zu einem unwichtigen Punkt - jede Vorlage wird nur einmal kompiliert, danach wird der Vorlageninhalt aus (viel schnellerem) Cache ausgegeben.

Das Problem bei der Verwendung eines XML-Parsers ist, dass HTML nicht immer wohlgeformtes XML ist. Selbst wenn Sie gültiges XHTML verwenden, können Sie in Situationen geraten, in denen Sie HTML-Entities unterstützen müssen, und dann stoßen Sie auf Randfälle wie eingebettetes Javascript, usw. (Anmerkung am Rande: Meiner Meinung nach ist dies das größte Versäumnis von HTML5 - es verwirft nicht diesen ganzen veralteten SGML-Kram und besteht darauf, wohlgeformtes XML zu verwenden. Wenn das HTML-Gremium dies getan hätte, wären zukünftige Templating-Engines viel einfacher zu schreiben mit standardisierten XML-APIs.) Ich habe vor einiger Zeit eine XML-basierte Vorlagen-Engine geschrieben, diese verwendet die XMLReader-API, aber um sie mit HTML zu verwenden, müssen Sie Einträge in Ihr Libxml-Systemverzeichnis hinzufügen. Das funktioniert gut genug, aber es ist umständlich, die meisten Leute würden einfach aufgeben und etwas einfacheres verwenden.

Answer 2

Hier sind einige der mir bekannten XML-basierten Vorlagen-Engines:

http://phptal.org/

http://code.google.com/p/querytemplates/

http://www.hyperkit-software.com/projects/phptemplates/index.html

In Bezug auf die Leistung denke ich nicht, dass die meisten XML-basierten Vorlagen-Engines in der Kompilierungsphase signifikant schneller sind - die meisten modernen Vorlagen-Engines für PHP verwenden eine Kompilierung, sodass die Leistung des Compilers im Allgemeinen zugunsten einer erweiterbaren und wartbaren Engine-Basis sowie der Erstellung optimierter kompilierter Vorlagen geopfert wird. Wie Robin bereits sagte, kümmert sich niemand darum, wie schnell oder langsam die Kompilierungsphase sein kann, da die Vorlagen kompiliert sind.

Es gibt jedoch andere Argumente für XML-basierte Vorlagen-Engines. Persönlich mag ich nicht die Idee, zwei verschiedene Tag-Syntaxe zu mischen, von denen eine (Smarty) nicht mit herkömmlichen XML-Tools analysiert, verarbeitet oder validiert werden kann. Zur Klarstellung, ja, Sie können den XML-Teil einer Smarty-Vorlage analysieren, aber Sie können die Smarty-Tags nicht analysieren oder ändern, da sie für ein XML-Tool wie Text aussehen.

Ein weiteres gängiges Argument gegen eine benutzerdefinierte Syntax (wie sie in Smarty und den meisten anderen Vorlagen-Engines verwendet wird) ist, dass PHP bereits eine Syntax für alles bereitstellt, was diese Vorlagen-Engines bieten - zum Beispiel ist name)?> ähnlich wie {$person.name|ucfirst} in einer einfachen PHP-Vorlage. Es verwendet eine Syntax, die bereits den PHP-Entwicklern bekannt ist, was bedeutet, dass es keine Lernkurve, keinen Kompilierungsschritt, keine bereitgestellte Engine, keinen Laufzeitaufwand für das Rendern der Vorlage usw. gibt.