sinn von template-klassen?

mathik

Hallo leute!

ich habe mich mal mit templating beschäftigt und mir mal die template klasse vlibTemplate angeschaut, und mir ist der sinn solcher klassen irgendwie nicht klar.

was ist denn der unterschied wenn ich schreibe:

//template.tpl
<tmpl_var name="variable">

//php code
$templ = new vlibTemlate("template.tpl");
$templ->setVar("variable", "inhalt der variable");
$templ->pparse();

oder das hier:

//template.tpl
<?php $variable ?>

//php code
$variable = "inhalt der variable";
require("template.tpl");

ich meine was hat so eine template klasse denn für vorteile? ich sehe da ehrlich gesagt nur nachteile:
die template-datei wird geparst und und alle tmpl* tags werden durch den entsprechenen php-code ersetzt. dann wird dieser mit eval ausgeführt und die ausgabe davon dann ausgegeben.

ich meine, sowas ist doch ziemlich lahm und speicheraufwendig.
außerdem ist das sehr unflexibel. warum macht man das nicht gleich so wie oben?

PS: ich bezweifle nicht den sinn von templating, sondern von diesen template-klassen.

Shade Of Mine

Original erstellt von mathik:
PS: ich bezweifle nicht den sinn von templating, sondern von diesen template-klassen.

puh, beinahe hätte ich einen vortrag über templating gehalten...

aber das ist mir auch schon aufgefallen, viele PHPler haben 0 Ahnung von effizients oder OOP.

vorallem was da manchmal in klassen gesteckt wird, oder was es da für komische codes gibt *graus*

also bitte, frage bloss nicht was sich manche leute dabei denken (PHP ist zu einfach, zieht nur anfänger an, so ähnlich wie die VCL von Borland!)

Sa*n*dman

... viele PHPler haben 0 Ahnung von effizients oder OOP.
... PHP ist zu einfach, zieht nur anfänger an ...

Na ganz so schlimm ist es nun auch wieder nicht. Es gibt durchaus gute Gründe für den Einsatz von PHP, und einer davon ist eben diese Einfachheit. Deshalb sind es eben nicht nur Anfänger, die damit arbeiten. Abgesehen davon würde ich einen Großteil der Schuld für das mangelhafte OOP vieler Skripte eher in der doch recht bescheidenen Unterstützung seitens der Skriptsprache suchen.

Aber kommen wir zurück zum Thema:
1. eval und include/require sind seit Version 4 annähernd gleich schnell. Es gibt also wenig Gründe, die eine Methode der anderen vorzuziehen.

2. Ein häufiger Grund für die Verwendung aufwändiger String-Ersetzungen ist die Historie einiger Template-Klassen. Viele dieser Klassen basieren auf bestehenden "Template-Dialekten", welche bei einer Konvertierung älterer Projekte (häufig Programme die mittels CGI eingebunden wurden) erhalten bleiben sollen. Der Hintergedanke ist dabei natürlich wie so oft die Kosten-Ersparnis, schließlich ist es nicht grade billig eine komplette Online-Redaktion in einem neuen "Dialekt" zu schulen.
Neben diesem Grund gibt es aber natürlich auch noch die viel zitierten "Anfänger", die sich bei Ihrer ersten Template-Klasse einfach nur Teile aus anderen Projekten abschauen oder sich zumindestens in der dialektischen Ausprägung daran orientieren.

3. Trotz der offensichtlichen Performance-Probleme implementierter Template-Dialekte gibt es aber auch Vorteile dieser Methode. So ist es zum Beispiel unter Sicherheitsgesichtspunkten manchmal durchaus sinnvoll, dem Template-Ersteller die Verwendung von PHP im Template zu verweigern, also keine Auswertung mittels eval oder require/include vorzunehmen. Es gibt schließlich durchaus Bereiche, in denen man selbst seinen Redakteuren nicht unbedingt trauen kann oder Bereiche in denen diese einfach (unabsichtlich) zuviel kaputt machen können.

Gruß Jens

Shade Of Mine

Original erstellt von Sa(n)dman:
Na ganz so schlimm ist es nun auch wieder nicht. Es gibt durchaus gute Gründe für den Einsatz von PHP, und einer davon ist eben diese Einfachheit. Deshalb sind es eben nicht nur Anfänger, die damit arbeiten. Abgesehen davon würde ich einen Großteil der Schuld für das mangelhafte OOP vieler Skripte eher in der doch recht bescheidenen Unterstützung seitens der Skriptsprache suchen.

jo, s gibt auch viele profis. aber es gibt auch viele anfaenger,w as ja ansich kein problem ist, nur gelingt es jedem anfaenger eine template engine oder ein forum zu schreiben...

Die OO Unterstuetzung in PHP ist nicht besonders gut, aber man kann trotzdem ordentliche sachen machen.

nur letztens habe ich in einem Buch folgendes gelesen:

class Directory
{
  //whatever
}

class Entry extends Directory
{
  //whatever
}

dabei sollte wohl klar sein, ein Entry kann NIE NIE NIE ein Directory sein...
Directory sollte viele Entries haben...

naja, sowas sehe ich aber recht oft...

du redest von professioneller software - jo, da gibts viel gutes. smarty zB ist nicht schlecht. aber es gibt auch viel mist

ich will keineswegs PHP schlecht machen, aber mich nervt es wenn jeder der gerade mal 1 Monat PHP programmiert und vorher nur Basic erfahrungen hat, eine Template Engine schreibt (so weit habe ich noch kein problem damit) und sie dann als super dupa geil darstellt (ab hier nervt es).

keine frage, es gibt wirklich exzellente software, aber teilweise ist sogar bei PEAR manchmal mist drinnen...

hallo sandmann,

die punkte 2. und 3. machen natürlich sinn, solche template-klassen zu verwenden.

aber wenn das projekt in php entwickelt wird, dann ist punkt 2 kein argument für eine template-klasse. ein webdesigner sollte wohl in der lage sein, seine template-tags mit dem entsprechenden php-code ändern zu können...

punkt 3 spricht schon eher für die verwendung solcher klassen. allerdings sollte dann das template nur _einmal_ geparst werden, und der daraus resultirende php-code vewendet werden.

Gruß mathik

Sa*n*dman

@Shade Of Mine

... nur letztens habe ich in einem Buch folgendes gelesen: ...

Jetzt hast Du nen zentralen Punkt erwischt: Leider gab (oder gibt es teilweise sogar noch) eine Zeit, wo jeder Anfänger ein Buch verfassen konnte und auch noch nen Verlag gefunden hat, der ihm das ab nimmt. Ich hab schon so einige PHP-Bücher quergelesen und bin in fast jedem auf schwerwiegende Fehler gestoßen.

... aber teilweise ist sogar bei PEAR manchmal mist drinnen...

Stimmt. Auch mich erstaunt die Struktur in einigen PEAR-Packages immer wieder. Vor allem das Mime-Mail-Package darf man sich eigentlich nicht von innen anschauen. Allerdings muß man auch bei PEAR immer wieder im Hinterkopf behalten, daß eine größere Entwicklergemeinschaft dahinter steckt, und daß jeder dieser Entwickler einen unterschiedlichen Kenntnisstand mitbringt. Als ich meine ersten Miniatur-Änderungen am PHP4-Source vorgenommen habe, ist auch ziemlich viel Mist dabei raus gekommen und die Bugfixes, die letztendlich im offiziellen Sourcetree auftauchten waren oftmals viel Effektiver.

Irgendwann hat halt jeder mal klein angefangen. Grade die Tatsache, daß der eigentliche Source immer wieder aus solchen Gründen überarbeitet werden muss, schafft umgekehrt betrachtet auch in größeren Entwicklergemeinschaften immer wieder Verbesserungspotential.

@<mathik>

... ein webdesigner sollte wohl in der lage sein, seine template-tags mit dem entsprechenden php-code ändern zu können...

Natürlich sollte er dazu in der Lage sein, aber leider erlebt man in der Praxis immer wieder, daß es garnicht so einfach ist, liebgewonnene Zöpfe abzuschneiden. Normalerweise ist es ja eben nicht so, daß Du ein Projekt komplett neu und als allererstes aufziehst, sondern daß bestehende Systeme erweitert werden oder eben durch eine PHP-Lösung ersetzt werden. Und da ist es halt oftmals billiger eine Template-Engine zu implementieren, als alle bestehenden Templates zu überarbeiten.

... allerdings sollte dann das template nur _einmal_ geparst werden, und der daraus resultirende php-code vewendet werden.

Das Konzept, das Du hier implizierst, hat leider einen schwerwiegenden Nachteil:

Wenn man so vorgeht, wie Du es jetzt vorschlägst, dann muss man
1. den Template-Dialekt durch PHP ersetzen.
2. evtl. bestehenden PHP-Source im Template aus Sicherheitsgründen zumindestens teilweise in Entities umwandeln.
3. den enstandenen PHP-Source dann evaluieren
Daraus resultieren zwei Probleme:
1. Die Performance. Du musst (wg. 2.) eine zusätzliche Ersetzung über das komplette Template vornehmen und Du hast noch den Overhead durch die Bytecode-Generierung und -Auswertung (in 3.).
2. Es lassen sich bei komplexen "Dialekten" oftmals nicht alle Tags so einfach in PHP-Source umwandeln, evtl. treten also sehr aufwendige Regex-Ansammlungen auf.

Im Idealfall würde ich die Struktur des Templates komplett parsen und daraus eine Baumstruktur generieren. (Je nach Template-Dialekt liesse sich dafür z.B. die XML-Extension oder DOM-XML mißbrauchen.) Zusätzlich bräuchte man dann nur noch ein zweites Array mit Referenzen auf die zu ersetzenden Nodes (zur Vermeidung aufwändiger Suchoperationen). In diesem Array würde ich dann all meine Ersetzungen einfügen und am Ende aus dem Baum ein neues Dokument generieren. Problematisch dabei ist nur, das für sowas valide XHTML-Templates und der passende Template-Dialekt zusammenfallen müssen - und sowas passiert leider eher selten. Wenn DOM-XML endlich mal den Experimental-Aufkleber los wird, dann sollte sich damit eine recht fixe Template-Engine mit weitgehend variablem Syntax und vor allem sehr kompakten PHP-Code basteln lassen.

Natürlich ist bei so einem Konzept immer vorausgesetzt, daß dem Webdesigner kein direkter PHP-Zugriff gestattet werden soll, aber zumindestens bei den komerziellen Varianten, die mir bisher so über den Weg gelaufen sind, stand das eh eigentlich immer im Pflichtenheft.

Gruß Jens

Shade Of Mine

Original erstellt von Sa(n)dman:
Stimmt. Auch mich erstaunt die Struktur in einigen PEAR-Packages immer wieder. Vor allem das Mime-Mail-Package darf man sich eigentlich nicht von innen anschauen. Allerdings muß man auch bei PEAR immer wieder im Hinterkopf behalten, daß eine größere Entwicklergemeinschaft dahinter steckt, und daß jeder dieser Entwickler einen unterschiedlichen Kenntnisstand mitbringt.

ich habe wirklich nichts gegen anfaenger - ich helfe jeden wo ich nur kann.

aber mal ehrlich: mit 1 oder 2 Monaten Programmiererfahrung schreibe ich doch kein package fuer PEAR, oder? das macht keinen sinn, denn man kann es halt noch nicht gut genug.

Gerade bei PEAR stoert das gewaltig, denn PEAR waere ja, wenn es eine qualitaetskontrolle gaebe verdammt gut. nur momentan ist es halt so, dass es in der mittelmaessigkeit versinkt.

eine ordentliche qualitaetskontrolle und PEAR waere standardmaessig bei einer PHP installation dabei.

Irgendwann hat halt jeder mal klein angefangen. Grade die Tatsache, daß der eigentliche Source immer wieder aus solchen Gründen überarbeitet werden muss, schafft umgekehrt betrachtet auch in größeren Entwicklergemeinschaften immer wieder Verbesserungspotential.

jo, genau deiner meinung.
aber bitte doch nicht solche sachen dann als gut hinstellen und allen leuten anbieten. lieber von profis meinungen einholen und weiter ueben!

Original erstellt von Sa(n)dman:

Das Konzept, das Du hier implizierst, hat leider einen schwerwiegenden Nachteil:

Wenn man so vorgeht, wie Du es jetzt vorschlägst, dann muss man
1. den Template-Dialekt durch PHP ersetzen.
2. evtl. bestehenden PHP-Source im Template aus Sicherheitsgründen zumindestens teilweise in Entities umwandeln.
3. den enstandenen PHP-Source dann evaluieren
Daraus resultieren zwei Probleme:
1. Die Performance. Du musst (wg. 2.) eine zusätzliche Ersetzung über das komplette Template vornehmen und Du hast noch den Overhead durch die Bytecode-Generierung und -Auswertung (in 3.).
2. Es lassen sich bei komplexen "Dialekten" oftmals nicht alle Tags so einfach in PHP-Source umwandeln, evtl. treten also sehr aufwendige Regex-Ansammlungen auf.

Gruß Jens

ich habe mir bis jetzt nur eine template-klasse von php angeschaut: vlibTemplate
und dort gibt es folgende tags: <tmpl_var>, <tmpl_loop>, <tmpl_include>, <tmpl_phpinclude>, <tmpl_comment>, <tmpl_if>, <tmpl_elseif>, <tmpl_else>, <tmpl_unless>, <tmpl_endloop>,
<tmpl_endcomment>, <tmpl_endif> and <tmpl_endunless>.

und ich wüsste nicht, welches man hier nich durch php-code ersetzen könnte.
denn in der klasse wird das intern auch so gemacht.

was ich meine ist, dass diese tags nur _einmal_ durch php-code ersetzt werden. der daraus resultierende php-code soll dann benutzt werden, und nicht bei jedem seitenaufruf jedes mal von der tempalte-klasse geparst werden.

was gibt es denn eigentlich noch so für template-"dialekte", die nicht direkt in php-code umgewandelt werden können?

diese xml-geschichte, die du ansprichst, hat ja das selbe konzept, wie die template klassen auch. nur dass dort halt xml benutzt wird. schneller ist das keineswegs nur standard-konformer. man müsste dann zumindest keinen eigenen parser schreiben.

Gruß mathik

Sa*n*dman

@Shade of Mine:

eine ordentliche qualitaetskontrolle ...

Naja, bis zu einem gewissen Grad gibt es ja eine Quallitätskontrolle durch die Mailinglist. Allerdings ggeht die bei weitem noch nicht genug in die Tiefe, sondern sie orientiert sich erstens noch zu sehr an der Funktionalität des ganzen und setzt INHO zu stark auf den Maintainer - besonders im Falle das dieser noch recht "grün" hinter den Ohren sein sollte.

... und PEAR waere standardmaessig bei einer PHP installation dabei.

Ich weiß ja nicht, wie das bei den vorkompilierten Packages aussieht, aber zumindestens im CVS-Tree ist PEAR standardmäßig dabei.

@Mathik:

.. und ich wüsste nicht, welches man hier nich durch php-code ersetzen könnte.
denn in der klasse wird das intern auch so gemacht. ..

Da habe ich mich wohl etwas ungenau ausgedrückt - die Betonung meines Satzes sollte auf dem "einfach" liegen. Ich bin jetzt mit den Innereien von Claus' Template-Engine nicht so vertraut, aber speziell die Loops und die If-Auswertung läßt sich je nach Ausprägung der logischen Bedingungen nicht so einfach realisieren.

was ich meine ist, dass diese tags nur _einmal_ durch php-code ersetzt werden. der daraus resultierende php-code soll dann benutzt werden, und nicht bei jedem seitenaufruf jedes mal von der tempalte-klasse geparst werden.

Du sprichst von einer Art vorkompilierter Templates. Diese Methode hat durchaus Ihre Vorteile und wird auch bei einigen Template-Systemen eingesetzt, allerdings ist der letztendliche Geschwindigkeitsvorteil dieser Methode minimal. Mit einem vernünftigen Template-Cache, inklusive HTTP/1.1-gerechter Nutzung des Browser-Caches, sind ähnlich performante Systeme auch zu erreichen, wobei hier noch das geringere anfallende Datenvolumen die Anbindung (und somit u.Umst. die Rechnung) entlastet. Mit beiden Methoden lassen sich durchaus performante Template-Engines realisieren.

diese xml-geschichte, die du ansprichst, hat ja das selbe konzept, wie die template klassen auch. nur dass dort halt xml benutzt wird. schneller ist das keineswegs nur standard-konformer. man müsste dann zumindest keinen eigenen parser schreiben.

Doch, das ganze ist durchaus schneller. Wenn Du einen Text-Parser in PHP realiserst, dann ist zwar der Aufwand der gleiche, der Overhead ist durch die zusätzliche Bytecode-Generierung aber größer, womit der Gesamtaufwand wieder steigt. Bei SAX oder DOM hast Du den Vorteil, daß die Routinen "hardcoded" zur Verfügung stehen und somit eine geringere Lade und Verarbeitungszeit veranschlagen - eben weil ein großer Teil des Overheads durch den Interpreter wech fällt.

Vereinfacht ausgedrückt:
Stell Dir mal vor, Du willst in einem String alle "a" durch "b" ersetzen. Du hast nun zwei Möglichkeiten:

1.als Funktion:
function my_replace( $from,$ to,haystack){ for(i=0; $i<strlen($ haystack); $i++) if($ haystack{i}==from)
haystack{i}=$to;
return haystack; } 2\. per str_replace(): str_replace(from, $to,$ haystack);

Je größer nun $haystack wird, desto größer gerät dabei der Geschwindigkeitsvorteil von str_replace() (auch wenn bei sehr kleinen Strings hier noch die For-Schleife im Vorteil ist)

Gruß Jens

Shade Of Mine

Original erstellt von Sa(n)dman:
**Ich weiß ja nicht, wie das bei den vorkompilierten Packages aussieht, aber zumindestens im CVS-Tree ist PEAR standardmäßig dabei.
**

ich meinte auf professionellen servern.
wir haben kein PEAR, und unser Chef sieht nicht ein wozu er tw. solchen muell raufspielen sollte