chunky

Smarty ist recht weit verbreitet. Die Smarty-Syntax hat sich meines Erachtens als ein Standard für Templates durchgesetzt. Sie ist einfach zu erlernen und Designer kommen damit recht gut zurecht.

Bei der Suche nach einer Template-Engine, die nicht mit unnötigen Funktionen vollgeladen ist, aber trotzdem eine zu Smarty kompatible Syntax hat, bin ich auf Outline gestossen. Die Engine scheint mir ein wenig "under-exposed" zu sein. Kann ich nur empfehlen.

Mister Ad

McSodbrenner

Ohne jetzt Werbung für eigene Programmierung machen zu wollen:
Ich kann Serpent empfehlen. Das einzige Feature, dass eine eigene Syntax rechtfertigt, ist ja die Template-Sicherheit in Bezug auf die Weitergabe der Templates. Da ich das nie brauchte, bin ich halt den anderen Weg gegangen und habe einfach PHP um ein paar sehr nützliche Template-Features (Sehr kurze Syntax für PHP-Tags, Template Inheritance, Punkt-Syntax für Arrays etc.) erweitert. Herausgekommen ist halt Serpent, dass bei uns in der Firma sehr gut ankam (alles langjährige Smarty-Benutzer).

Outline habe ich mir damals vor dieser langen Pause des Entwicklers angeschaut. War sehr interessant (gerade für Smarty-Liebhaber), genau wie Dwoo. Wobei mir Dwoo auch wieder vom Code zu mächtig war.
Twig ist natürlich deshalb interessant, weil es einen relativen starken Rückhalt halt (Fabian P. ist ja nicht so unbekannt ). Allerdings wieder das Problem einer eigenen Syntax.

__________________
http://mcsodbrenner.blogspot.com/
Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

Destruction

Moin Moin,

wollte schon nen eigenen Post machen, bin aber jetzt zufällig auf diesen hier gestoßen.

Ich bin mir über den Sinn von Smarty auch noch nicht ganz im klaren!

Habe mich jetzt 2 Tage bissl reingearbeitet alles angeschaut... gelesen und gelesen...
Aber irgendwie ist Smarty mit so vielen Funktionen vollgestopft die für mich keinen Sinn machen

Ich habe nach einer Template Engine gesucht, um einfach wirklich PHP-Code von HTML-Code zu trennen.

Da ich jedoch selbst beide Parts übernehme kann ich den größten Teil nicht gebrauchen ( Funktionen wie |upper , |lower usw. usw. das kann ich ja alles im PHP-Code machen ).

Werde mir jetzt mal ein paar kleinere Template-Engines anschauen glaube ich.
Macht für mich mehr Sinn als das überladene Smarty.

Btw.: Weiß jemand ob Smarty 3 schon "stabil" läuft? Gerade die foreach-Schleife hat mir nämlich bei Smarty 2 überhaupt nicht gefallen =/ =/

__________________
"Dummheit redet viel..Klugheit denkt und schweigt.." [Amgervinus]

nikosch

Siehe #3.

Ansonsten: Klar - man kann alles in PHP machen (ist ja schließlich selbst eine Abstraktion der View). Aber darum gehts ja nicht. Sondern um einen standardisierten Layer, der vor allem View-Aufgaben abbildet.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

McSodbrenner

Klar, kann man natürlich machen, aber genau das sind ja Sachen, die kein bisschen die Applikationslogik betreffen, sondern nur das Aussehen. Und dann sollten sie natürlich auch ins View bzw. in die Template Engine.

Wie die Entwickler von Smarty ja auch so schön sagen: "Genauer gesagt erlaubt es die einfache Trennung von Applikations-Logik und Design/Ausgabe." Nicht von PHP und HTML.

__________________
http://mcsodbrenner.blogspot.com/
Serpent PHP Template Engine: http://code.google.com/p/serpent-php-template-engine/

Destruction

Btw noch mal eine evtl. doofe Frage aber:

Ich muss ja um z.B. Daten aus einer Datenbank darzustellen erst mal die ganzen Daten der Datenbank durchlaufen und in einem array speichern und dann noch mal im Smarty-Template die Daten durch eine Schleife jagen...
Ist das nicht für die Performance ziemlich .... schlecht?

Grüße
Destruction

__________________
"Dummheit redet viel..Klugheit denkt und schweigt.." [Amgervinus]

Flor1an

"ziemlich schlecht" ... im Verhältnis zu was? Natürlich muss etwas mehr berechnet werden, aber ob es wirklich so viel Performance kostet wenn eine Array durchlaufen wird? Ich glaube eher nicht ...

__________________
▇█▓▒░◕‿‿◕░▒▓█▇

mquadrat

Ich habe einen gänzlich anderen Weg gewählt. Die Oberflächen werden mittels OO zusammengebaut. Also mehr in Richtung klassischer Desktop-Programmierung. Die einzelnen Komponenten rendern sich dann selber und am Ende wird alles zusammengebaut. Für reine CMS Aufgaben zwar etwas umständlich, aber sobald man datengetriebene Anwendungen betrachtet IMHO sehr viel schneller und eleganter.

Wobei ich im Moment überlege, die Struktur nicht nur als PHP OO zur Verfügung zu stellen, sondern auch als XML. Damit würde das Auto-Generieren von Oberflächen oder ein "Oberflächen-Baukasten" nochmal wesentlich einfacher. Könnte man dann wieder vorkompilieren beim ersten Aufruf oder so.. *grübel*

Alternativ läßt sich unser Framework, das wir verwenden aber auch mit Smarty oder irgendwas anderem befeuern. Ein weiterer Vorteil des OO-Aufbaus

__________________
Wir suchen PHP / Delphi und .NET Entwickler im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

leonv

Der XML Ansatz klingt doch viel netter, dabei kannst du einfach ein DOMDocument Object weiter reichen und von überall darauf zugreifen ("devide and conquer").

Von Smarty kann ich allein schon wegen der Sicherheit abraten, DOM ist sowieso mit an Bord und beherrscht wunderbar HTML-Ausgaben.

__________________
Kreativität und Schöpfung durch Chaos und Ordnung.

Destruction

mhm?
Wieso das denn?
cu
Grüße
Destruction

__________________
"Dummheit redet viel..Klugheit denkt und schweigt.." [Amgervinus]