Heute war mein Tag der Entdeckungen. Ich entdeckte Smarty bzw. was genau Smarty tut habe ich entdeckt und was andere Skripte ohne eine Template Engine nicht tun. Nur weiß ich noch nicht ob das was es tut, besser ist als das was die anderen nicht tun, weil der eine sagt das ist Mist und geht auf die Performance und der andere sagt, dass das aber so viel einfacher und sauberer ist … wenn man denn mal verstanden hat warum das einfacher ist.
Für das Logbuch:
Heute habe ich mich außerdem bei Twitter angemeldet.
Hallo Jutta,
zu Smarty kann ich nur sagen, dass ich damit ein Projekt realisiert habe, bzw. immer noch realisiere. Mein Kollege kann so ungestört programmieren und ich mich um das Layout kümmern. Ideal!
Twitter nutze ich nicht und werde es wohl auch nicht nutzen… ein Dienst den die Welt nicht braucht :-)
lg markus
Ja, Template-Sprachen. Bin ich ehrlich gesagt kein Fan von :)
PHP ist ursprünglich eine Template-Sprache, warum eine neue erfinden? Warum ist {meineSpezielleVariable} einfacher als <?=$meineSpezielleVariable?> Der Unterschied ist nur, dass man bei der Verwendung von PHP eben nocht deutlich mehr kann als Smarty (z.B. eigene Output-Funktionen definieren) und dass man die Daten, die man ausgeben kann, in PHP mittels Arrays besser hierarchisch strukturieren kann.
Naja, bisher hat mich noch kein Argument wirklich überzeugt.
@Mathias: Da gebe ich dir auch Recht, PHP kann deutlich mehr. Aber wenn ich mich nur mit dem Layout beschäftigen möchte und von PHP wenig Ahnung habe, dann ist es einfach perfekt.
Wir arbeiten zu zweit an diesem Projekt, er ist der Entwickler, ich der Gestalter. Ich arbeite an der Oberfläche und er gleichzeitig an der Entwicklung des Systems dahinter. Perfekt. Wenn das kein Argument ist :-)
@markus:
Das bestreite ich gar nicht. Ich sag ja auch nicht, dass man als Designer PHP kennen muss. Aber wo ist der Unterschied?
Smarty: {$meineVariable}
PHP: <?=$meineVariable?>
Smarty: {if $meineVariable}…{else} {/if}
PHP: <? if($meineVariable): ?> …<? else: ?> … <? endif; ?>
Das kann man beliebig fortsetzen. Man braucht gar nicht den gesamten Funktionumfang von PHP können, ein paar einfache Strukturen reichen. Das braucht man aber auch bei Smarty. Ich seh da einfach keinen Unterschied, nur dass man eben – wenn man will – noch viel mehr machen kann.
@Jutta: nette Diskussionsgrundlage! Danke dafür.
@Mathias: Ja, da gebe ich dir recht. Allerdings ist es einfach angenehmer wenn man sich nur auf das Layout konzentrieren kann.
Ist aber denke ich eine Glaubensfrage.. :-)
Es bewahrheitet sich eben doch, dass man in Blogs einfach mal raus muss mit der Sprache, mit seinen Fragen und unausgegorenen Überlegungen, die ja ein Webdesigner nicht immer ganz zu Ende denken kann, weil ich z.B., auch wenn ich das Thema Smarty in etwa begriffen habe, das noch nicht in einem solchen Umfang durchschaue wie Programmierer das tun.
Aber, Mathias, da sind wir wieder beim Thema und deinem Bemühen die Welt, wie Webdesigner sie sehen, zu verstehen ;-) Für dich ist das mit Programmiersprache so wie mit dem Lesenlernen. Hat man einmal die Bedeutung begriffen, weiß man nicht mehr wie es war, als einem alle Buchstaben auf Ortschildern nichts weiter als kryptischer Zeichensalat erschienen.
Dein Beispiel ist nunmal ein sehr einfaches und in diesem Fall würde sich da auch aus meiner Sicht nicht viel tun bzw. würde ich die Vorteile einer template-engine nicht erkennen können.
Aber wie ist es mit Arrays. Da wird es aber doch schon komplexer. Von WP kenne ich es, dass man in den wp-template-tags bei vielen gewünschten Ausgaben die Parameter in einer gewissen Reihenfolge angeben kann udn damit eben den output selber regulieren. ich kann selber bestimmen ob ich eine ul drumherum haben will oder eine dl. OK – wenn man es kapiert hat, dann geht das schon. Ein Webdesigner jedoch fragt sich, ob er das kapieren muss und es ist aus „unserer“ Sicht sicherlich nicht uninteressant, aber doch zeitintensiv sich dareinzuschaffen. Andererseits muss man sich sicherlich in smarty auch erst reinfuchsen.
Für mich und damit komme ich auch auf eine zentrale Frage meines gestrigen (übermüdeten) Ausgangsposting zurück, wäre es jedoch auch wichtig zu wissen inwieweit eine template-engine die Performance einer Webseite beeinträchtigt. Immerhin muss das Zeuchs ja erstmal in die Variable rein und dann wieder raus. Wenn man vom Ulm aus nach München will um ein Eis zu essen, würde man dann mit einer Template-engine nicht bildlich gesprochen den Weg über Berlin nehmen?
Also wir sind gerade dabei unseren kompletten Code nachträglich auf Smarty umzustellen und ich finde es schon einen Segen, bevor wir überhaupt fertig sind.
Smarty zwingt einen (mehr oder weniger) das Design vernünftig vom Code zu trennen und fördert so teilweise Dinge im Code zu Tage, die vorher niemand gesehn hat.
Natürlich kann man das alles mit PHP-Mitteln auch hinbekommen (wobei Smarty ja eigentlich auch nichts anderes macht), aber die Dinge, die man sich dann selbst als Werkzeuge basteln müßte, bietet Smarty eben schon fertig an (Selbstgebaute Blockfunktionen find ich klasse und auch die Smarty Modifier lesen sich meiner Meinung nach wesentlich einfacher: nl2br(wordwrap(htmlentities($var), ENT_QUOTES, ‚UTF-8′), 50, „n“, true)) vs. $var|htmlentities:’all‘:’UTF-8|wordwrap:50:“n“:true|nl2br – Letzteres hat die Paramter vernünftig beieinader und liest sich von links nach Rechts in Ausführungsreihenfolge)
Ich war anfangs auch gegen Smarty, aber je mehr ich damit mach, desto mehr überzeugt mich das Ding.
Naja, smarty macht das recht geschickt. Das Parsen ist erstmal sehr aufwendig. Dazu ist es noch in PHP geschrieben, was nochmal langsamer macht (den Geschwindkeitsunterschied zwischen PHP-Scripten und C-Programmen – wie eben der PHP-Parser – sind sind gewaltig. Und mit gewaltig meine ich wirklich gewaltig.). Diese Prolematik sind sich die Smarty-Entwickler bewusst, weshalb sie sich das Ergebnis in einem Cache zwischenspeichern. Damit ist das Problem nicht mehr so extrem. Das ist also erstmal nicht wesentlich schlechter. Kleiner Umweg, aber das hält sich in Grenzen.
Arrays sind auch in Smarty möglich, jedoch nicht mit Klammer-Struktur, sondern mit „Punkt“-Struktur – ähnlich zu Objekten in Java. Im wesentlichen sehe ich als Unterschied nur, dass man eben in PHP Funktionen schachtelt (wie das z.B. Nitek zeigt), in Smarty alles hintereinander schreibt. Ob das einfacher zu lesen ist? Auf jeden Fall ist es eben eine gewisse Strukturierung, die man erst mal lernen muss und an die man sich dann mit der Zeit gewöhnt.
Jetzt kann man natürlich sagen, dass man ja Smarty anbieten kann, tut ja nicht weh. Das Problem ist: ich habe schon einige Projekte gesehen, die Smarty verwenden, dann aber mitten im Code PHP-Anweisungen haben, weil irgend etwas bestimmtest nicht in Smarty geht. Das ist dann mehr als hässlich! Und ich will dabei betonen: der PHP-Code macht in den Templates durchaus Sinn, da sie wirklich nur eine spezielle Formatierung wollten. Also keine Programmlogik oder so, nur Ausgabelogik.
Ein Gestalter (Webdesigner/Layouter/Webmaster/HansDampf) der nicht versteht wie die Technik dahinter funktioniert, ist für ein Projekt meistens eher hinderlich. Um ein recht drastisches Beispiel zu geben: Wenn der Kunde den Designer sagt das sich das Logo doch bitte drehen und blinken soll, der Designer dann dem Programmierer fragt ob man das mit PHP machen könne, kommt das Projekt an einen Punkt wo sehr viel unnötige Kommunikation stattfindet.
Für mich ist das immer so, als wenn ein Testfahrer sagt das der Motor zu wenig Durchzugskraft hat wenn man versucht im fünften Gang anzufahren.
Man kann zwar Design/Layout und Programmierung strikt voneinander trennen (sollte man vielleicht auch), aber trotzdem sollte sowohl der Designer als auch der Programmierer wissen was der andere da macht.
Bei den „Vorteilen“ warum man Smarty verwenden soll, wird als erstes „Designers can’t break application code.“ genannt. Wenn der Designer weiß was da im Hintergrund passiert, sollte dies ebenso wenig passieren. Mehr noch, wenn der Designer weiß was da passiert, hat er, wie Mathias schon sagte, mehr Möglichkeiten.
Zudem ist Smarty eine weitere Sicherheitslücke. Der Programmierer muss zusätzlich kontrollieren was der Designer an Ein- und Ausgabemöglichkeiten einbaut. Kennt der Programmierer sich nicht wirklich mit Smarty aus, steht er schnell vor einem neuen Problem.
Smarty kommt auch nicht ohne PHP aus. Wie im Crash Course von Smarty zu sehen ist, müssen erst einmal die Daten an Smarty übergeben werden bevor sie im Template angezeigt werden können. Wer übernimmt die Arbeit? Der Programmierer (PHP) oder der Designer (Smarty)? Und wer bestimmt welche Variable wie heißt bzw. welche Inhalte sie bekommt?
Aus Sicht des Programmierers eine feine Sache. Wird eine Variable „GeheimesPasswort“ nicht zur Verfügung gestellt, kann der Designer sie auch nicht verarbeiten. Wird allerdings die Variable „ZweiteAdressangabe“ nicht zur Verfügung gestellt und der Programmierer ist im Urlaub, kann sich der Designer dumm&dusselig designen, er kommt nicht voran.
Noch schlimmer wäre es, wenn z.B. die Variable {ZweiteAdressangabe} den Wert der Variablen „GeheimesPasswort“ enthält.
Smarty ist demnach eine weitere Fehlerquelle. Die Suche und Behebung von Fehlern erzeugt unnötige Arbeit und ist ebenfalls ggf. eine Sicherheitslücke.
Meiner Ansicht nach erschwert Smarty die Entwickelungsarbeit ungemein. Es ist eine weitere Fehlerquelle, eine weitere Sicherheitslücke und beide Seiten, Design und Programmierung, müssen sich auf eine weiteren Ebene absprechen.
Smarty erleichtert dem Designer in manchen Punkten die Arbeit ein wenig. Das meiste sollte aber auch mit CSS zu schaffen sein und dafür wurde es ja erfunden.
PS: Warum kann man sich weniger auf seine Arbeit konzentrieren wenn man spitze Klammern anstatt geschweifte verwendet?
Wir haben inzwischen ca. 90% unsere Codes auf Smarty portiert und ich hatte an keiner Stelle das Bedürfnis PHP-Code ins Template zu klatschen – Eigene Modifier haben wir natürlich gebraucht, aber die leigen ja schön aufgeräumt im Plugins-Verzeichnis.
Die Lesbarkeit wird IMHO schon deshalb erhöht, weil ich nichtmehr suchen muß, welche Klammer nu wo zu geht (was bei längeren ausdrücken, mit 5, 6 geschachtelten Funktionen schon mal verwirrend werden kann). Außerdem stehn die Modifier in „natürlicher“ Reihenfolge – Rückwärtslesen entfällt, was angenehm ist, auch wenn man es als Programmierer eigentlich gewöhnt ist.
Was die Performance angeht kann ich noch nicht sooo viel sagen, aber ich gehe nicht davon aus, dass dadurch etwas spürbar aufwändiger wird (schon gar nicht, wenn man brav assign_by_ref für größere Objekte verwendet).
Wer sich sorgen um die PHP-Performance macht sollte sich ohnehin erstmal EAccelerator, XCache und Co anschaun – Mit derartigen OP-Code-Caches läßt sich die PHP-Performance signifikant steigern ohne auch nur eine Zeile Code zu ändern.
Naja, dass nur bestimmte Variablen zur Verfügung gestellt werden, halte ich eigentlich schon für sehr sinnvoll. Es ist Aufgabe des Programms, festzulegen, welche Variablen zur Verfügung stehen. Das halte ich ehrlich gesagt schon für ein wichtiges Design-Muster. Das unterscheidet jetzt nicht unbedingt PHP von Smarty, eher das grundlegende Design-Konzept des Programms.
Ein unfähiger Designer kann mit Smarty natürlich genauso Schaden anrichten, aber doch zumindest schonmal ein ganzes Stück weniger, als mit PHP – Smarty schützt einen nicht vor Dummheiten, aber allein schon durch die sauberere Struktur, die damit entsteht hilft es, Dummheiten zu entdecken.
… ich ergreife die Gelegenheit beim Schopf und frage mal weiter. Stellt euch vor, ein Webdesigner hat Kundenanfragen mit den unterschiedlichsten Anforderungen. Hier sehe ich es als meine Aufgabe auch immer wieder die Nase ins Web zu stecken und vorhandene Programme zu testen, zu schauen was sie tun, wie sie laufen und funktionieren, was Vor- und Nachteile sind und für welchen Einsatz sie geeignet sind. Diesbezüglich habe ich schon einiges lokal getestet. Würde ich auf Systemen, die ich für gut befinde, ein Design draufschrauben wollen, ist es jedoch immer die Frage wie man das bei dem jeweiligen System macht. Sicherlich gibt es bei allen Ähnlichkeiten und Übereinstimmungen, aber bei jedem System muss ich doch immer wieder neu herausfinden, was ich im Markup für Variablen (Platzhalter oder was auch immer) setzen muss bzw. wie ich die schreiben muss, damit ich meine Seite valide, semantisch und inhaltlich korrekt zusammenbekomme. Theoretisch und aus meiner Sicht, könnte ich mir vorstellen, dass einiges einfacher wäre, wenn man sich z.B. mit einer Template-engine auskennt und angebotene Systeme damit arbeiten. Zu theoretisch?
Ich würde sagen, das funktioniert nur theoretisch. Das liegt schon daran, dass du die Variablen je nach grundlegender Programmstruktur unterschiedlich bekommst. Ich denke aber, dass sich bei den meisten Systemen eine einheitliche Struktur finden lassen würde. Dazu müssten jedoch viele die Köpfe zusammstecken und sich auf ein Vorgehen einigen. Das halte ich für unmöglich. Nicht, weil alle Programmierer Dickköpfe sind, sondern weil jedes Vorgehen seine Vor- und Nachteile hat. Je nach Programmierer hast du da andere Prioritäten. Solange du sie nicht zwingen kannst, einheitlich zu arbeiten, sehe ich da keine Chance.
Smarty spielt seine Vorteile eigentlich da aus, wo Programmierer und Designer nicht an einen Tisch sitzen. Zum Beispiel bei Blog-Software wie WordPress und S9Y.
Ein Template soll auch mit künftigen Versionen der Software zusammen funktionieren. Außerdem sollte das Template-Design unabhängig vom Software-Design möglich sein. Ein weiterer Vorteil ist die Wiederverwendbarkeit beim Wechsel der Software. Benutzen beide Systeme Smarty, kann man ein Template u.U. mit nur wenig bis gar keinen Anpassungen mit verschiedenen Systemen verwenden.
Die Vor- und Nachteile von Smarty zeigen sich bei WordPress sehr schön. Zum einen musste sich niemand zusätzlich mit Smarty auseinander setzen, was dazu geführt hat das recht schnell sehr viele Templates entstanden sind. Vor allem sind auch sehr speziell angepasste Templates entstanden, die weit über die Möglichkeiten hinausgehen die WordPress von Hause aus bietet.
Auf der anderen Seite gibt es reichlich Templates die nur ab bzw. bis Version X funktionieren. Diese Templates auch auf anderen Versionen lauffähig zu bekommen bedeutet entweder auf Funktionen zu verzichten oder erheblich viel Mehraufwand.
Ich würde für mich als Faustregel festhalten:
– Sitzen Designer und Programmierer an einem Tisch, dann ist Smarty eher hinderlich. Das PHP-Code schlechter lesbar wäre als Smarty-Code kann ich kaum nachvollziehen. Ansonsten wären wohl PHP-Programmierer die meiste Zeit damit beschäftigt ihren eigenen Code zu entschlüsseln. Auch müssen ja nicht alle Ausgaben hard codiert im Template stehen. Steht irgendwann fest welche Ausgaben wie formatiert werden müssen, kann dies von der Programmierung erledigt und als Funktion angeboten werden.
Smarty bringt hier einiges an Overhead mit falls man nur wenige Funktionen von Smarty benötigt.
– Sitzen Designer und Programmierer nicht an einen Tisch, wie es z.B. bei Blog-Software i.d.R. üblich ist, dann kann Smarty einige Vorteile haben: Templates können über verscheidene Software-Versionen hinweg verwendet werden, u.U. auch mit verschiedenen Software-Systemen. Template-Designer müssen sich über die verschiedenen Funktionen der Software keine Gedanken machen. Sie haben einen Satz an Variablen der zur Verfügung steht und das was Smarty an Funktionen zur Verfügung stellt. Ein „Mehr“ gibt es allerdings auch nicht.
Serendipity (S9y) ist mit Sicherheit keine schlechte Software. S9Y hatte bereits vor Jahren einige Features die WordPress neuerdings als „weltbewegend“ ansieht. Trotzdem ist S9Y nicht unbedingt die erste Wahl wenn es darum geht eine Blog-Software auszuwählen. Ich denke es liegt nicht zuletzt daran das S9Y Smarty in den Templates verwendet und somit die Entwickelung von Templates die den Funktionsumfang erweitern erheblich einschränkt.
vielen Dank für euren tollen Beiträge. Das hat mir jetzt doch geholfen, Smarty besser einzusortieren. Ich glaube, dass Ralf es ganz gut auf den Punkt gebracht hat, denn in der Vergangenheit ist es in der Tat so, dass wenn ich entweder mit dem Programmierer selber zusammenarbeite oder ein sehr gutes Hilfeforum aufsuchen kann, es eigentlich auch nicht so das Problem ist und war, wenn ich mal hier und da was nachfragen muss. Kann mich über mangelnde Auskunfstbereitschaft jedenfalls nicht beschweren.
Andersrum bin ich auch jemand, der gerne immer irgendwelche Vorschläge bezüglich der Bedienfunktionen oder macht um dies und das noch zu verbessern. Vielleicht wäre es mit der Umsetzung für den Programmierer dann wirklich schwerer, wenn man durch so etwas wie Smartie erstens ausgebremst wird und zweitens für den Progammierer unnütze, zusätzliche Arbeit entsteht und dann auch noch für etwas, was mich in Sachen Einblick in die Programmierung nicht wirklich weiterbringt. So habe ich das noch nicht gesehen … Danke!