Mailinglisten-Archive |
Hi Wilfried, Wilfried J. Klein Redaktion ''Der CMS-Report'' schrieb: > natürlich braucht die "Präsentationsschicht" auch ein paar Platzhalter, > die > vom Parser gefüllt werden ... ab und an sogar ein Schleifen-/if-konstrukt > oder ein Template-Include. Aber das war's dann auch, also einige wenige > Tags, die der Parser effizient abarbeiten kann. > > Ich finde ein solch methodisches Entwickeln genial und ich nutze diese > Methodik auch nur noch ... ganz konsequent. Und das Ergebnis sind kleine > modulare Scripte und stets valider Output. ja, das stimmt. Dasselbe erreiche ich mit der Template Engine, die PHP als Sprache verwendet. Ich habe in der Diskussion, die ich hoch spannend finde, den Eindruck gewonnen, daß es wohl ein Bißchen auch eine philosophische Frage - oder gar eine Glaubens-Frage? :-) - zu sein scheint, ob man eine gängige Template Engine bevorzugt oder einen anderen Ansatz, der auf PHP und nicht einer separaten Templatesprache beruht. Vielleicht hatte Tobias auch deswegen Angst, einen Krieg auszulösen, als er PHP als Template Engine bezeichnete... :-) Vielleicht kommt man der Sache auch näher, wenn man die Zielsetzung einer Template Engine betrachtet und die Anforderungen, die man an eine Template Engine stellt. Auf der Smarty-Website sind ja ein paar Punkte aufgelistet, wofür z.B. Smarty gut ist: http://smarty.php.net/whyuse.php Mir geht es beispielsweise nur um die Kernfunktion, also die Trennung von Anwendungslogik und Präsentation, insbesondere auch mit dem Ziel verschiedene Ausgabeformate auf der Präsentationsebene bedienen zu können (XHTML, WAP, XML, PDF, XML, RTF usw.). Mein Anspruch ist, daß die Lösung möglichst effizient und ohne unnötigen Overhead sein soll. Vorstellungen wie, der Programmierer braucht sich nicht ums Layout zu kümmern und der Designer hat nichts mit der Anwendungslogik zu tun, widersprechen einfach meinen praktischen Erfahrungen. Sicherheitsaspekte spielen für mich in dem Sinne bei der Template Engine eine untergeordnete Rolle, daß ich Templates, die mir ein Externer erstellt hätte, vor der Freigabe immer selbst prüfen würde, um sicherzustellen, daß sie erstens funktionieren und zweitens nichts auf meinem Server tun, was ich nicht will. Es ist zwar nett, daß Smarty alles schön kapselt, also keinen - vielleicht bösartigen - PHP-Code ausführt und bei Fehlern nicht das PHP-Skript abbricht, aber viel weiter bin ich damit auch noch nicht, weil die Ausgabe auf der Website dann nicht stimmt. Kontrolle muß also ohnehin sein. Trennung von Programmierer und Designer hin oder her. :-) Das sieht jetzt sicherlich der eine oder andere anders, aber so seh ich das. :-))) Viele Grüße Lutz
php::bar PHP Wiki - Listenarchive