[php] =?iso-8859-1? =?us-ascii?Q?_=3D=3Fus-ascii=3FB=3FUT9SRTpfPTVCcGhwPTVEX0VtcGZlaGx1bmd fZj?= 1GQ3JfVGVtcGxhdGVzX 1N5?= stem? =

[Tobias Daur]

> Statt dessen moechte ich lieber ein wenig die Entstehung
> dieser Library skizzieren, vielleicht wird damit einiges
> klarer.

Whow, Danke für die Ausführlichkeit.

> Warum nun nicht Smarty oder aehnliche? Ganz einfach: Ich halte
> es nach wie vor fuer Unfug, Programmlogik, die eigentlich
> gerade durch den Einsatz von Template aus der HTML-Ebene
> heraus gehalten werden soll, nun durch die Verwendung
> einer Template-Klasse, in der sich quasi wieder programmieren
> laesst, wieder in die HTML- bzw. Design-Ebene hereinzuholen.

Ich denke, hier sind wir am Knackpunkt. Und am Ende der Diskussion -
denn man kann sich entweder dafür entscheiden, alle Logik ins Script zu
packen und in die Templates reines HTML mit ein paar Marken, oder aber
dafür, in den Templates selber den Teil der Logik anzulegen, der mit der
Ausgabe und Darstellungsweise zu tun hat.

Ich gehe daran nicht prinzipiell sondern pragmatisch ran:
Meinem HTMLer hilft es sehr, wenn ein Template nicht in tausend
Schnipsel geteilt wird, sondern je nach Komplexität an einem Stück
bleibt oder aber noch ein oder zwei Untertemplates hat. Dann behält er
die Übersicht. Dazu benötige ich aber Logik (Schleifen, Bedingungen) im
Template.
Außerdem soll er die Möglichkeit haben, die Dinge, die ihn direkt
betreffen, auch selber zu beeinflussen. Ein IMHO gutes Beispiel ist die
von mir schon erwähnte Möglichkeit, einen String nach einer bestimmten
Zeichenzahl abzuschneiden und mit einem "..." zu versehen. Hier muß der
HTMLer in seinem Code die Werte so lange ändern können, bis sein Code
paßt, ohne dafür auch nur ein Wort mit dem Programmierer zu wechseln.

Dazu ist es aber nicht sinnvoll und nötig, daß er sich von Grund auf mit PHP
beschäftigt oder seine HTML-Datei mit Code anreichert, der da nicht
nötig ist.

Die Trennung von PHP und HTML schafft Übersicht auf beiden Seiten und
reduziert den Codeumfang und die Entwicklungszeit. Die Festlegung der
Logik ausschließlich auf die PHP-Seite scheint mir zwar die reine Lehre,
aber nicht der effektivste, praxisgerechte Weg zu sein.

> Du meinst, dass der Ansatz von PHPLIB Template, IT/IT[x],
> etlichen der oben genannten sowie auch Apolda Template
> nicht funktioniert? Das erklaer' mal den vielen Anwendern
> jener Template-Klassen, die seit Jahren (Apolda Template
> hier ausgenommen) mit deren Hilfe ihre Projekte realisieren... ;-)

Klar funktioniert der. Die Frage ist doch nicht: Welche Wege gibt es?
Die Frage ist: Welches ist der beste Weg - bei einer bestimmten
Arbeitsteilung. Templatesysteme wie PHPLIB sind IMHO einseitig aus
Programmierersicht entwickelt. Es geht ausschließlich um die Auslagerung
von HTML, alles andere bleibt in der Hand des Programmierers.
Die umgekehrte Perspektive nimmt PHP-Temple von Jörg Krause ein: Auch
bei komplexeren Standardaufgaben wird keine Zeile PHP nötig, weil die
Templatesprache dem HTMLer alles bietet, was er benötigt.
Smarty scheint mir der ausgewogene, praxisgerechte Mittelweg zu sein.

Natürlich führt eine mächtige Templatesprache zu einem großen Paket,
dieser Nachteil, den ja auch Kai kritisiert, wird IMHO überzeugend durch
das selbständige Erzeugen und Aktualisieren zusammengeführter Dateien
aus Script und Template gelöst.

Aber Du hast mich neugierig gemacht - ich schaue mir Apolda noch mal in
Ruhe an :)

Viele Grüße

Tobias