Wer will den var.key[key] schreiben??? Entweder var[key] ODER var.key halte ich für sinnvoll, aber eine KOMBINATION daraus ist eher unsinnig...

@Dracaelius:
Ändert sich eigentlich nach Änderung einer Datei die gecachte Datei automatisch (beim nächsten Aufruf) mit oder müsste man da bei Änderungen durch das Admin-Center auch die Datei durch eine Abfrage löschen lassen?

Bis wann kann ich mit der Version 1.03 rechnen?

@LonelyPixel:
Hast ein schönes Forum gebastelt. Jabber-IM ist doch sowas ähnliches wie ICQ oder? Wenn ja, wieso hast du dann nicht (zumindest wahlweise) auch ICQ integriert?

Normalerweise muss von der Cache-Verwaltung erkannt werden, ob die Datei neu compiliert werden muss.

Jabber ist ein offenes, XML-basiertes Instant Messaging and Presence System, genau. Urspruenglich gab es in meinem Board nur E-Mail und ICQ-Benachrichtigung, spaeter kam Jabber dazu, und dann hat sich ICQ dazu entschlossen, automatisiertes Absenden von Nachrichten zu unterbinden. Naja, gib mir ne PHP-Library fuer ICQ, dann bau ich's vielleicht wieder ein. Bis dahin musst du dich mit einem offenen, erweiterbaren, mittlerweile RFC-konformen System begnuegen, das der kommerziellen Konkurrenz noch zu denken geben wird. ;)

Wie kann ich Daten aus der DB in folgendes FOrmat bringen?
Jeweils Titel1, Titel2,... und Inhalt1, Inhalt2,... soll aus der Datenbank kommen.
Zu beachten, in der letzten Zeile ist KEIN Komma!
Jede Zeile wird per Schleife (while) aus der DB geladen und soll in das Array eingefügt werden. Die Anzahl der Arrays sollte Variabel sein (abhängig von den Ergebnissen auch der DB)...
Ich bin mit meinem begrenzten Wissen da leider noch nicht weitergekommen :(

Dazu musst du erstmal wissen, wie du auf deine Datenbank zugreifen kannst. Dazu gehoert natuerlich auch, was fuer eine DB das ueberhaupt ist... Das PHP-Manual sollte hier weiterhelfen.

Okay, mein Fehler.
MySQL. ABfrage funktioniert und wird per while-Schleife ausgelesen.
Das Ergebnis wird z.B. in $result (oder wie auch immer) abrufbar sein.
Es geht also nur um die "Format-Änderung"

$boxen['boxtitel'] und $boxen['boxinhalt'] in das array als 'titel' => wert bzw 'inhalt' => wert.
Und das logischerweise für jedes Vorkommen.
Damit will ich Boxen erstellen, diese in das array übergeben und das array wird dann dem TPL-Parser übergeben, in dem per foreach-Schleife das ganze dann ausgegeben wird...

Ich hoffe das war verständlicher. Habe schon verschiedene meiner Gedankengänge getestet, was entweder zu keiner Ausgabe oder einem Fehler geführt hat...

Dein letzter Beitrag lässt mich stark vermuten, dass du bereits dazu in der Lage bist, Daten von einem Array in ein anderes zu schreiben. foreach war das Stichwort. Mir ist also unklar, was es da noch zu erklären gibt. :confused:

Okay, ich habe es jetzt geschafft, habe einen kleinen Fehler gemacht. Ging mir nur drum zu sehen, ob mein Lösungsweg falsch war oder ich einen Fehler eingebaut habe. Ich zähle mich immernoch zu php-Anfängern ;)

Hi,

sorry das ich das Thema wieder hoch hole, allerdings glaube ich das {var} nicht so ganz funktioniert in der Klasse oder Irre ich mich da? Am Code selber habe ich nichts verändert.

Ja, in der aktuellsten Version sind einige Fehler drin, ich habe aber bisher nicht die Zeit gefunden, diese zu beseitigen. Ich arbeite zurzeit auch an genug anderen Projekten, daher wird dies in absehbarer Zeit auch nciht geschehen.

Ja kein Problem, ich wollte nur sicher gehen, das ich nicht einen Fehler gemacht habe. Wenn du die Fehler beseitigt hast mal melden, gefällt mir nämlich die Template Engine :)

Ich kann ja mal versuchen den Fehler auszumerzen wenn ich ihn denn finden sollte ;)

Ich interessiere mich auch für diese Template Class. Hab beim lesen vorhin garnet auf das Erstell-Datum geachtet^^.
Werde die Klasse bei Gelegenheit auch mal testen :D

Ich hab mir inzwischen eine eigene Template-Klasse gebastelt :D
Diese verwende und teste ich auch schon in einem eigenen Projekt

Hi!
Ist zwar mitlerweile schon ein halbes Jahr her seit der letzten Antwort, hab die template-Klasse aber erst jetzt endeckt und bin finde sie eigentlich ganz gut!
Gibt es da mitlerweile ne neue Version oder eine die einwandfrei funktioniert?
Danke!
Gruß Felix

Nein, ich habe daran nicht mehr weiter gebastelt, hatte irgendwann einen Festplattencrash und die neuste Version noch nicht gesichert. Danach ist mir die Lust vergangen und ich habe für mein Software-Projekt Smarty genommen. Vorläufig ist von mir aus auch nicht mmit neuen Versionen zu rechnen, vielleicht werde ich für meine andere Software eines Tages nochmal schreiben. Wann und ob überhaupt sowas stattfinden wird, kann ich aber im Moment noch nicht sagen.

Wenn wir gerade dabei sind: Da ich auch mit den Gedanken spiele, neben einer komplexen Datenbankklasse mir auch einmal eine komplexe, eigene Templateklasse ala Smarty zu programmieren (für mich selbst), die Frage, was kann den, Fabchan, deine Templateklasse? Was hast du für Erfahrungen, was eine Templatecklasse haben sollte? Ich rede jetzt nicht von simplen wie if, elseif, else, eine Ausgabe und eine PHP-Cache.

@frederic:
Seine Template-Klasse (ich beziehe mich auf die ältere Version 1.02(?)) war nach einem guten Konzept aufgebaut und recht einfach im Code. Ich habe mir eine eigene geschrieben, die auf dem gleichen Prinzip beruht.
Je nachdem welchen Weg du einschlägst, wirst du auf verschiedene kleinere oder größere Probleme stossen, die es zu lösen gilt.
Ich habe einige Gehversuche gemacht und fremde Projekte angeschaut, bis ich den für mich passenden Weg gefunden habe.

@Fabchan:
Solltest du diese ältere Version noch haben, so stelle doch einfach diese mal bereit. Ich fand diese sehr lehrreich und gut, wenn auch einige für mich wichtige Funktionen gefehlt haben.


Meine TPL-Klasse ist leider völlig undokumentiert und inzwischen auch nicht mehr im Betrieb, da ich mein eigenes Projekt aus Zeitgründen momentan auf Eis gelegt habe. Vielleicht setze ich mich mal irgendwann (...) an die Doku und stelle diese doch bereit...

Entschuldigt, dass ich bisher nicht wieder geantwortet habe, stehe im Moment etwas unter Zeitdruck, vielleicht habe ich nächste Woche zeit, mich nochmal darum zu kümmern.

Ich kenne das Problem mit dem Zeitdruck, also keine Panik ;)

mal ne andere frage..
ich nutze auch eine eigene simple template klasse, die weit weniger kann als deine (trenne halt gerne html und php)
aber ich hab letztens if-else abfragen eingebaut
klappt wunderbar, jedoch kann ich sie nicht verschachteln. geht das bei deiner klasse??
mfg

Björn: Entweder du übersetzt die If-Strukturen des TPLs in PHP und führst es anschließend mit eval() aus oder du schreibst dir einen Parser, der den Code Zeichen für Zeichen nach If's durchsucht (hab ich mal gemacht: sehr zeitaufwendig und komplex).

Ja, das Problem kenne ich. Verschachtelte Tags zu erkennen erfordert etwas mehr Aufwand, mit regulären Ausdrücken allein ist das nicht lösbar. (Jedenfalls nicht einfacher als ohne.) In meinem BBCode-Parser sowie meiner Template Engine habe ich daher einen zweiteiligen Ansatz verfolgt: Zuerst wird in einer normalen (weitestgehend optimierten) Schleife die Eingabe auf interessante Stellen durchsucht, in diesem Fall die Tags oder z.B. if/endif-Anweisungen, und danach wird jede Stelle einzeln analysiert und ggf. mit regulären Ausdrücken in die Zielsprache konvertiert (hier HTML bzw. PHP). So kann man gezielt auch die Verschachtelung der Anweisungen prüfen und im Fehlerfall reagieren, bevor es PHP oder der Browser (auf meist recht brutale Weise) tun. Falls es dich interessiert, kannst du dir den Code in einer etwas älteren Version ja unter http://px.no-ip.com/proj/ute/ mal anschauen. ;) Die aktuellste Version hab ich in meinem Forum (siehe Signatur) verbaut.

@Björn:
Geht sowohl bei seiner als auch bei meiner Klasse ;)
Der Code wird immer erst in php gewandelt und, sofern gecacht werden soll, in eine Datei geschrieben.
Somit wird beim ersten Aufruf des Templates der geparste Code mit eval ausgeführt und das zweite mal einfach die Cache-Datei includet.

so ist es bei mir auch :) es geht ja auch mehr ums verschachteln..

@eBoy: Ich sehe gerade, dasss Version 1.02 auf der ersten Seite dieses Themas ist, leider ist der Parser für IF-Konditionen noch nicht wirklich ausgereift und teilt diese nur anhand von Leerzeichen in mehrere Teile auf. Das war nur als vvorübergehende Lösung gedacht, um erstmal wieder was online zu stellen, aber ich glaube, in Version 1.03 habe ich einen besseren Parser für Ausdrücke. Hinzu kommt noch, dass Version 1.02 mit regulären Ausdrücken arbeitet und ich muss selber zugeben, dass die Methode von LonelyPixel mit dem Zeichen für Zeichen durchgehen um einiges besser ist.

Das mit dem Parser ist übrigens auch im vBulletin 3 ganz gut gelöst, also wer eines besitzt, sollte sich ruhig mal mit dem Quelltext etwas befassen!

Ich werde wohl doch mal meine herauskramen und dokumentieren, da sollte das alles funktionieren und der Code verständlich sein

Template-Parser sollte fehlerfrei funktionieren und die Dokumentation habei ich mal grob erstellt, jedoch muss ich noch einen rechtlichen Hinweis/ Copyright einfügen und habe da bisher noch keinerlei Erfahrung, wie man das formuliert bzw. was da alles drinstehen sollte...

hrrmmmhum. *räusper* *staubwegwedel*

Ich stelle das hier jetzt einfach mal zur Diskussion:

http://www.phpguru.org/static/templating.html

Ich machs jetzt nur noch so, obwohl mir die Entwicklung von geeigneten Parsern für Templates 'n Heidenspaß gemacht hat. Aber tatsächlich hat die hinter dem Link beschriebene Vorgehensweise unbestreitbar was für sich.

Leider scheint der Autor nicht zu wissen, dass die Schreibweise mit <? und ?> als deprecated gilt und somit ist der Spaß aus Sicht von PHP 5 sehr unsauber, auch wenn man sagen muss, dass es net verkehrt ist. Das beste Beispiel, für eine "PHP-Template-Engine" ist meiner Meinung nach WordPRess, die benutzen auch einfach PHP-Code und es funktioniert wunderbar, allerdings nicht so:
sondern eher so:
Und dann muss man sich schon fragen, ob man nicht doch lieber {$post.author} oder irgendwas ähnliches schreibt....

Natürlich, jeder nach seiner Fasson. Vorteile liegen jedoch auf der Hand: Bei vernünftiger Kapselung braucht man so

1) nicht schon wieder ne neue Dreckssprache zu lernen ;)
2) sich um Performance keine (größeren) Sorgen zu machen
3) sich nicht darum zu scheren, wer die Sachen nach einem pflegt: Jeder, der PHP mindestens im Spaghettistadium beherrscht, kommt auch damit sofort ohne nennenswerten Einarbeitungsaufwand zurecht
...

Deprecated ist da eigentlich nichts. Leider ist der einzige Nachteil der "faulen" Schreibweise, dass das ganze nicht mehr wohlgeformt nach XML-Ansprüchen ist. Soweit ich weiß ist die Verwendung von <?PHP ?> auchd er einzige Weg, wenn man seine Scripte PEAR-tauglich halten will.

Ich denke aber mal, dass bei der Verwendung von "richtigen" Templatesprachen (es sei denn man baut auf Java-ähnliche Taglibs, die wiederum XML-Konform sind, aber meistens den Nachteil einer grottigen Performance haben) da in Einzelfällen noch viel mehr Probleme auftauchen können.

Außerdem: Wir reden von Templates, nicht von Skripten. Und selbst wenn man die "lange" Schreibweise bevorzugt, hindert einen ja nichts daran, diese auch zu verwenden.

Und selbst wenn ich fauler Hansel mal über meine <? ?> stolpern würde, dafür gibts ja immer noch S+R ;)

Naja, wie gesagt, ich wollte das einfach einmal zur Diskussion stellen, ich finde jedenfalls, dass sich die ganze Sache bis jetzt für mich nur gelohnt hat. Nie mehr Templatewuseleien :D

Ich habe meine eigene kleine Klasse, die vom Prinzip her der von Fabchen's älteren Version nicht unähnlich ist und halte das für eine sehr gute und saubere Lösung. Ich mag es nicht php-Code (logischerweise in php-Tags) in "HTML-Dateien" stehen zu haben.
Grundsätzlich: Jedem das seine ;)
Ich will auch kein Smarty (aufgebläht) oder XML (nochwas zu lernen), deshalb bleibe ich bei php und html ;)

Als ich meine Template-Lib entworfen hab, hatte ich einen ganz guten Artikel zur Vorlage, der mir was über den Sinn und die Aufgaben von Templates erzählt hat, und dessen Autor am Schluss auch PHP verwendet hat. Mag ja sein, dass das schön ist, aber wer PHP kann, wird sich nicht schwer tun, ähnliche Sprachen zu lernen. Es geht hier ja nicht um universelle Sprachen wie Japanisch oder Vietnamesisch mit zigtausend Symbolen und feinen Variationen, vielmehr um vielleicht 20 Vokabeln die man größtenteils bereits kennt. Außerdem sehe ich in der Erschaffung einer neuen Sprache die Möglichkeit, diese genau auf den Einsatzzweck zu optimieren. Ich habe z.B. Konstrukte eingeführt, mit denen man ganz einfach durch eine Liste laufen kann, ohne danach ständig den selben Variablennamen zu wiederholen (foreach ohne Laufvariable). Außerdem wird man bei PHP-Templates wohl garantiert auch nicht ohne Einarbeitung auskommen. Man muss in jedem Fall nachschauen, wie die Variablen heißen, wie sie organisiert sind (Arraystrukturen, Objektmethoden etc.) und vielleicht noch wie man sie verwenden sollte (Coding Conventions). Ob ich das in PHP oder <MyTemplate> mache, dürfte weitestgehend egal sein. Da anspruchsvolle Template-Systeme direkt in PHP übersetzen und zwischenspeichern, besteht nach diesem einmaligen Aufwand kein weiterer Performanceunterschied. Es entscheidet allein der Nutzen und die Effizienz der Sprache. Hier sehe ich individuelle Sprachen, oder zumindest spezielle Templatesprachen, klar im Vorteil.

Ui xml ist xml kannste ruhig lernen, das ist ne ziemlich feine Sache... va, wenn man "mal schnell" Dokumente in HTML umwandeln will... XSL als "Templatesprache" allerdings ist schon ein wenig umfangreicher, das stimmt schon.

Wenn man tatsächlich nur ein paar Kontrollstrukturen und Variablenplatzhalter braucht, sehe ich den Einsatz einer Templatemaschine tatsächlich nicht ein. Mittlerweile aus der Erfahrung jedenfalls nicht mehr. Wenn man sich diverse OS und auch kommerzielle CMS anschaut, bekommt man das kalte Gruseln, weil tatsächlich fast jeder auf andere (eigene) Sprachen setzt, die im Grunde - und da hast du wohl recht - immer wieder dasselbe machen :D.

Das "feinste", was ich mal gesehen hab, war ein System namens myView. Das Frontend war praktisch komplett in einer absolut grausamen Templatesyntax, durchmischt mit HTML, umgesetzt. Hier wurde dabei allerdings so viel Programmlogik mit eingebaut, dass man es tatsächlich auch hart in Basic oder so hätte kodieren können, an Unübersichtlichkeit war das nicht mehr zu übertreffen.

Wenn schon Templates, dann wenigstens schlank und mit so wenig Logik aus der Anwendungsebene wie irgendwie möglich, darin sind wir uns wohl einig. Und ich finde, dass für die paar Sachen, die dann noch übrigbleiben, ein wenig PHP durchaus ausreicht, ohne unlesbar zu werden... da ist der Einsatz eines ressourcenfressenden Templateparsers imho wiederum der berühmte Schuss aus Kanonen auf Spatzen.

Ich habe bis vor kurzem selber Smarty benutzt (im CalitrixWiki ist es, leider, noch drinne). Ich halte mittlerweile weder von Templateengines wie Smarty noch von Plain-PHP-Templates etwas.

Was spricht gegen Smarty?
Man implementiert eine komplette Scriptsprache die in den meisten Fällen die gleiche Funktionalität wie PHP hat - lediglich in einer leicht unterschiedlichen Syntax. Der oft postulierte Vorteil - Designer müssten sich nicht mit PHP rumschlagen - ähnelt da einen Witz. Wo ist der große Komplexitätsunterschied zwischen {foreach from="$foo" item="blah"} ... {/foreach} und <?PHP foreach($foo as blah) {?> ... <?PHP } ?>? Kaum vorhanden, würde ich sagen ...
Ob man etwas wie Smarty oder Plain-PHP verwendet macht vom Aussehen und der Funktionsweise keinen besonders großen Unterschied.

Was spricht gegen PHP?
Für mich vorallem Sicherheitsaspekte. Wenn ich, wie im CalitrixWiki, multiple Themes unterstütze fangen Benutzer früher oder später an, eigene Themes zu erstellen und zum Download bereitzustellen. Ich für meinen Teil würde so ein Theme nicht bei mir einsetzen, schliesslich möchte ich nicht fremden PHP-Code auf meinem Webserver ausführen. Ich könnte zwar alle Templates nach böswilligem PHP-Code durchsuchen aber das ist mir a) zuviel Stress und b) keine Lösung für einen Benutzer der kein PHP kann.

Für eine kleine Anwendung die ich für meine eigene Website baue, ein Gästebuch zum Beispiel, sind PHP-Templates aber eine gute Lösung. Man hat keinen Stress und zusätzlichen Overhead durch eine Templateengine und da man sowieso nur selber an dem Layout bastelt kann man die Sicherheitsbedenken auch beiseite wischen.


Ein anderer Ansatz
Die Idee dazu ist mir gekommen als ich mich in meiner Firma in typo3 einarbeiten sollte. Dort gab es die möglichkeit einen HTML-Parser für Templates zu verwenden und die einzelnen (HTML)Bestandteile über ihre Tags und IDs anzusprechen.

Nehmen wir ein Beispiel: ich will eine Liste registrierter Benutzer anzeigen. Mit einer Engine wie Smarty geh ich folgendermaßen vor:

Ich frage mich jetzt: wozu der Umstand, wenn ich jeden Bestandteil der Tabelle auch über HTML-Tags und Element-IDs identifizieren kann? Erweitern wir einfach mal das Template:

In PHP könnte ich das Template jetzt einwandfrei ansprechen (nur als Beispiel):

Die Funktion Template::loopThrough(); würde jetzt hergehen, die Tabelle mit der ID "user-table" suchen, in der Tabelle nach einem <tr> suchen der <td>-Elemente mit class-Attribut enthält und die <tr> in einer Schleife durchlaufen und die Daten aus $data einsetzen.

Das Ganze ist jetzt nur beispielhaft und vielleicht noch nicht so richtig durchdacht. Mit der Methode kann man sich aber eine extra Templateengine inkl. extra Scriptingsyntax sparen: die Funktionalität um HTML nach Elementen zu durchsuchen ist mit PHP5, DOM und XPath bereits gegeben. Das ist auch für den Designer schön weil er sich nicht mit Templatescripting rumschlagen sondern lediglich sauberes HTML abliefern muss.

Eine Alternative wäre XML und XSLT, mit PHP5 ebenfalls ohne größere Probleme möglich.

Meine Meinung: Templateengines wie Smarty sind so nützlich wie Karies, es geht auch einfacher ...

Johannes, dein Ansatz hat einen entscheidenden Nachteil: Der Anwendungscode enthält Teile der HTML-Struktur. Was machst du jetzt, wenn ich mich entscheide, die Benutzer nicht in einer <table/>-Tabelle darzustellen, sondern mit <div/>s oder gar als <ul/>-Liste? Dann isses vorbei mit der Gestaltungsfreiheit. Die Grenze zwischen Anwendung und Template sollte weder vom Code, noch von der Darstellung abhängen. Oft hängen Templates vom Code ab, hier hängt mal der Code vom Template ab.

Ein anderer Anwendungsfall von Template-Scripting ist: Ich will mehrere Links anzeigen, alle mit einem Trennsymbol dazwischen, manche aber optional. Da sollen natürlich keine zwei Trennsymbole in Folge hin. Hier muss also im Template die Darstellung programmiert werden. Genauso könnte ich die Links ja auch als Liste oder alle ganz woanders darstellen, mit einem ordentlichen Templatesystem kein Problem. Hier wäre natürlich keine Behandlung der Trennsymbole notwendig.

Was spricht für mich persönlich gegen Smarty:
Mein eigenes System ist mindestens doppelt so schnell und die Codegröße ist weit weniger als die Hälfte (müsste nachschauen). Den Umfang von Smarty hab ich gar nicht komplett erfasst, das Ding kann jedenfalls viel zu viel für den Zweck für den es existieren sollte.

Man muss die Tabelle ja nicht als Tabelle ansprechen. Man kann sie auch generell als "Element mit der ID user-table" ansprechen. Im Übrigen denke ich, dass eine so extreme Abstraktion zwischen Anwendung und Präsentation nicht sinnvoll ist. Du produzierst eine Menge Overhead mit unglaublich ausgetüftelten Templateengines nur damit ein Benutzer beispielsweise statt <table> auch <ul> verwenden kann (was in 99% der Fälle sowieso nicht stattfindet). Ich würde keine Templateengine mit mehreren tausend Zeilen Code schreiben nur um in solchen Details eine zusätzliche Abstraktion zu bieten.

Mit der Methode die ich vorgestellt habe findet eine, meiner Meinung nach, ausreichende Schematisierung der Darstellung statt: ich habe ein HTML-Dokument welches einen Body enthält welcher wiederum bestimmte Elemente (einen Usertabelle beispielsweise) die ich von PHP aus ansprechen kann enthält. Wenn ich eine Usertabelle anzeige ist das eine Tabelle, keine Folge von <div> und auch keine Liste (die eh nicht mehrere Spalten unterstützt). Wie diese Tabelle dann dargestellt wird hängt weder von PHP noch HTML ab, das übernehmen Stylesheets.

Ob ich die Begrenzung einer Schleife mit den <tr>-Tags festlege oder mit zusätzlich eingefügten Scriptinganweisungen macht in der Darstellung keinen Unterschied. Trotzdem ist das ein gutes Beispiel weil es eine Sache verdeutlich. Du sagst: lass mir die Freiheit eine Linkfolge entweder mit manuellen Trennzeichen (| oder - oder ähnliche) oder mit anderen HTML-Tags darzustellen. Ich sage: schreib eine Linkfolge als Liste, die Darstellung wie Trennzeichen, horizontal oder vertikal, kannst du mit CSS machen.

In einem Punkt hast du aber recht: Templatescripting wie if/else-Konstrukte sind in meiner Idee nicht vorgesehen. Vielleicht findet sich da eine Möglichkeit aber soweit habe ich, wie weiter unten erwähnt, noch nicht gedacht.

Ich will nicht sagen, dass grundsätzlichere Änderungen am HTML-Code niemals nötig wären. Was ich sage ist, dass man seine HTML-Templates als eine Art Darstellungsschema verwendet welches von PHP aus ansprechbar und von CSS aus formatierbar ist. Meine Methode ist natürlich nicht "bullet-proof": wenn man das Darstellungsschema grundsätzlich ändern will hat man bei meiner Methode ein Problem da man eventuell auch in den Anwendungscode angreifen müsste. Vielleicht kann man das auch umgehen aber soweit hab ich noch nicht gedacht, das war eher eine spontane Idee ;)

In den meisten Fällen ist so eine grundlegende Änderung nicht nötig. Wer schreibt die Templates eines Forums oder Wikis grundsätzlich um? Die meisten passen Farben und Hintergrundbilder, vielleicht die Reihenfolge von Elementen, an aber keine grundsätzlichen Änderungen am HTML.

Man könnte auch soweit gehen und generell auf Templates verzichten. Solange deine Anwendung ordentliches HTML auswirft lassen sich die meisten Designänderungen mit Stylesheets machen.

Ein guter Punkt wenn man speziell gegen Smarty argumentiert: das Ding ist absolut überdimensioniert. Im Grunde ist es schon fast eine eigene Programmiersprache.

Sind ja auch nur knapp über tausend Zeilen. :)

Zu deiner Tabelle: abwechselnde Zeilenhintergründe. Sowas geht mit CSS? (Falls ja: sowas geht mit dem heute unterstützten CSS?)

Trennsymbole mit CSS? Selbe Frage wie oben.

Solche Dinge sind mit meiner bisherigen Methode eher schwierig zu machen, ja. War ja auch nur eine Idee, wie man sich für die grundlegenden Sachen wie Platzhalter, Schleifen usw. eine umständliche Scriptingsyntax sparen könnte. Die meisten Scriptinganweisungen dienen nur als Markierungen für die Templateengine damit sie weiss wo ihre Daten hingehören. Das kann man sich auch sparen indem man direkt das HTML manipuliert.

Man könnte aber auch bei meiner Idee Scripting (optional) anbieten. Ich hab in meinem ersten Beitrag typo3 erwähnt. Dabei habe ich mich auf die Template-Autoparser-Erweiterung bezogen die im Manual unter "Modern Template Building" beschrieben wird. Dabei können HTML-Templates direkt manipuliert werden. Die Manipulation läuft dabei über eine einfache Scriptsprache (die seperat vom Template definiert wird) mit der dann auch Dinge wie wechselnde Zeilenhintergründe (oder andere HTML-Tags für ein Element) realisierbar sind.

Find ich zwar für die meisten Zwecke einfach zuviel des Guten aber wenn es gewünscht wird kann man Scripting ja seperat anbieten ... Das hat nämlich den charmanten Vorteil, dass Designer sich nur um ihren HTML-Code kümmern müssen. Kein Gedanke an Templatescripting, Anwendungslogik u.ä. Diese Dinge macht die Anwendung selber bzw. lassen sich über Scripting konfigurieren.

Hi Fabchen!
Hast du vielleicht noch dein Templateparser in der Version 1.03?
Ich habe zwar mittlerweile eine eigene Templateklasse, bin aber überzeugt dass es noch das ein oder andere daran zu verbessern gäbe...!
Danke!
Gruß Felix

Sehe ich mittlerweile auch so. Nach einigem Rumprobieren bin ich von der obigen Idee auch wieder abgekommen (Bäumchen wechsle dich :D ). Oder sagen wir so: Man sollte die Anwendungsfälle berücksichtigen. Wenn ich eine in sich gekapselte Applikation schreibe (bspw. ein Datenbankfrontend für irgendwas), so komme ich damit sehr weit, viel weiter, als wenn ich erst mit groben Templategewurschtel hantieren müsste.

Schreibe ich allerdings eine größere Applikation, in der mehrere End-Anwender wiederum Styles meiner Seiten manipulieren können, so bietet sich eine Templatemaschine wiederum an, v.a. unter dem Gesichtspunkt, dass man Platzhalter auf mehrere Arten und Weisen interpretieren kann (so kann zB eine Blockmarkierung im Frontend durch ein bestimmtes Modul - welches wiederum hart kodiert ist - und im Backend eben durch ein Formular zur Auswahl ebenjener Module ersetzt werden).

Trotdem gehe ich nicht davon ab, dass die "üblichen" Templatesprachen meist genausoviel Logik in die Templates übertragen, als würde man es hart als PHP/ASP/whatever-Seite schreiben. Klar - ein Mindestmaß an Kontrollen sind sicherlich nötig (siehe das Beispiel bzgl alternierender Zeilenhintergründe), doch sollte man diese durch "gewöhnliche" for...if...else...endfor Konstruktionen abbilden?

Wie einer meiner Vorredner bereits sagte, lässt sich dies viel eleganter verpacken. Ich suche im Augenblick nach Möglichkeiten, solch häufig wiederkehrende Aufgaben auf möglichst einfache Tags zu übertragen. Ein Beispiel: Wie ist eine (hierarchische) Navigation mit Smarty darstellbar? Ist schon recht aufwendig, stelle ich mir vor, und lässt sicherlich für mehrere Menuebenen ne Menge Schrott in den Templates. Es SEI denn, man verfolgt den Ansatz, dass man das Menu hart codiert, und die HTML-Ausgabe auf einen Template-Platzhalter bindet. Ist aber recht unflexibel.

Ich hatte nun folgende Idee (die auch ganz gut funzt, aber sicher noch Erweiterungsfähig ist):

Ein gut lesbares Template, welches einen schönen Kompromiss zwiscehn Usability und "Mächtigkeit"/Funktionalität bietet, kann folgendermaßen aussehen:

Die Idee ist also, soviel Logik wie möglich in die Software zu übertragen, dem User gleichzeitig aber Mittel zur Verfügung zu stellen, diese Logik durch das Template manipulierbar abzubilden. Im Gegensatz zum Klassischen Ansatz, dem Template nur Daten zur Verfügung zu stellen, die durch die Logik generiert werden, wodurch im Template selbst wiederum sehr viel Rechnerei zur Auswertung der Daten anfällt (bspw. [rekursives?] Durchwandern eines Arrays/von Objekteigenschaften, um mehrere Verschachtelte Navigationsebenen aus ner Datenbank etc. darzustellen).

Was denkt ihr?