@combie: Wo steck da eval() drin?
Template Engine
Einklappen
X
-
-
da muss ich auch noch meinen Senf dazugeben:
gerade stelle ich meine Anwendung von einem eigenen kleinen Templatesystem auf das Zend Framework mit Model-View-Controller Logik um. Beide Lösungen haben für mich ihre Berechtigung. Die MVC Lösung verleitet natürlich dazu auch Applikationslogik ins View (=Template) zu packen - hier ist halt Diziplin gefordert. Außerdem kommt für eine einfach Seite ein nicht ganz unerheblicher Overhead in Form von zahllosen Klassen und Ableitungen zustande. Die Datumsprüfung: zur Prüfung eines Datums im deutschen Format - wie es der User nun mal eingibt bzw. wohl auch eingeben möchte - wird die Klasse Zend_Date vom Zend_Validate herangezogen -> über 5.000 Zeile COde ...
Aber auch die Templates haben für mich einen klaren Nachteil: warum soll ich Variabeln und Schleifen in einer Templateklasse registrieren um dann per PHP ein Template zu laden und die Platzhalter mit Code zu füllen statt die Werte gleich ins Template zu schreiben. Hier ist das View-Pattern deutlich schlanker und einfacher - wer mit Smarty eine Schleife erstellen kann, kann das acu hmit PHP Syntax - und die Trennung zwischen Logik und Design/Layout bekomme ich auch mit einem View-Pattern ohne Templatesystem.
Das für bzw. wider hängt m.E. deutlich von der Komplexität der Anwendung ab und ob nur ein oder zwei oder mehrere Personen für Wartung, Entwicklung und Pflege zuständig sind. Bei großen Anwendungen oder mehreren Personen setze ich auf Standards und nicht mehr auf selbst gebasteltes.
Kommentar
-
Okay, jetzt seh ich's auch. Diese Art von eval ist relativ ungefährlich. Ich habe Zweifel, ob das auch für Crake's eval() gilt. Was ich oben eigentlich sagen wollte: Wer keine Ahnung hat, sollte die Finger von eval() lassen. Wer es besser weiß, die Gefahren kennt und sie ausschalten kann, der darf diesen Hinweis gern ignorieren.
Kommentar
-
Original geschrieben von Schnoop
Wenn du eine sinnvolle Art von Caching suchst Pekka, dann nimm als Backend auf jeden Fall Memcache. Was Smarty da mit Caching veranstaltet ist auch nur nen großer Haufen Mist und Overhead erst Recht.Memcache ist sehr lecker.
Schön wäre natürlich trotzdem auch ein reines Output-Caching. Aber das schenkt sich bei den meisten dynamischen Applikationen auch nicht mehr viel.
Kommentar
-
Zitat von unset
Was'n Käse. Jede mir bekannte MVC-Implementierung in PHP hat keinerlei Template-Engine - abgesehen von der im Link beschriebenen Vorgehensweise...
Kommentar
-
Original geschrieben von Pturbo
Zitat von unset
Ich weiß zwar nicht wie viele MVC-Frameworks (auf PHP-Basis) du kennst, aber z.B. Symfony um nur eines zu nennen!
Kommentar
-
Wer sagt denn, dass die Template-Engine eine eigene Sprache jenseits von PHP haben muss?
Aber dazu auch hier ein Beispiel:
Zendframework - in die View-Scripte lassen sich PHP, alternative Templatesysteme (wie Smarty) oder auch noch andere via Zend_View_Interface implementieren.
Kommentar
-
Original geschrieben von onemorenerd
Das ist nicht Aufgabe einer Template-Engine.
Aua! Sowas sollte verboten werden.
Wenn ich konsequent den Nutzer- und den Verwaltungsbereich voneinander trenne und Nutzereingaben sorgfältig prüfe, lassen sich die Risiken eindämmen. Letztlich unterscheidet sich diese Vorgehensweise nur marginal von jener zum Eindämmen von SQL-Injections.
Oder anders: Jede Möglichkeit zur Eingabe von Daten durch Fremde stellt ein Sicherheitsrisiko dar. Dieses Übel würde ich nicht Funktionen wie eval() in die Schuhe schieben wollen.Zuletzt geändert von Crake; 10.10.2008, 19:48.[COLOR=red]Gesellschaftsforum.net[/COLOR] - Projekt zur Wiederbelebung der Diskussionskultur im Internet
[COLOR=orange]1st News[/COLOR] - Das Newsletterscript für den professionellen Einsatz
Kommentar
-
Alles Käse. Eval ist schlicht nicht nötig. Die Dinge, die ständig damit umgesetzt werden kann man auch anders lösen - ohne potentielle Riesenlöcher aufzureissen.
Wer keine Ahnung hat, sollte es einfach nicht benutzen. Und Blacklisting ist so oder so schon lange überholt.
Kommentar
Kommentar