Template Engine

[onemorenerd]

@combie: Wo steck da eval() drin?

[combie]

In dem kleinen unscheinbaren e im $pattern.

[Patrick_PQ]

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.

[onemorenerd]

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.

[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.

[pekka]

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.

Ja, darauf wirds wohl rauslaufen 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.

[Schnoop]

Ich weise da mal auf Zend_Cache hin. Eine Menge Backend und Frontend Möglichkeiten.

Einfach mal angucken.

[Pturbo]

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...

Ich weiß zwar nicht wie viele MVC-Frameworks (auf PHP-Basis) du kennst, aber z.B. Symfony um nur eines zu nennen!

[unset]

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!

Mit Symfony hab ich sogar mal gearbeitet. Wo wird da genau eine neue Template-Sprache benutzt?

[Pturbo]

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.

[Crake]

Original geschrieben von onemorenerd
Das ist nicht Aufgabe einer Template-Engine.

An dieser Stelle missverstehen wir uns wohl. Ob ich nun ein fopen(), ein file(), include() oder eine Datenbankabfrage innerhalb der Klasse ausführe, ist wohl eher nebensächlich. Selbstverständlich wurden die Funktionen für den Datenbankzugriff in einer separaten Klasse ausgelagert.

Aua! Sowas sollte verboten werden.

Kommt drauf an.

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.

[unset]

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.