2 + 1 Vorschläge zu S9y 1.5

[falk]

Hallo Serendipityaner,

ich habe mir mal die Alpha von Serendipity 1.5 angeschaut. Folgendes möchte ich hier mal zur Diskussion stellen:

Zuerst das für mich wichtige:

Ich wäre dafür, Vor- und Nachname der Blog-Nutzer in getrennten Feldern zu speichern. Das würde es. bspw. vereinfachen, eine Datenbank mit anderen CMS/Foren/Wasweißich zu teilen, die Vor- und Nachnamen getrennt verlangen. Vielleicht könnte man diese Funktion über ein Plugin nachrüsten, aber wenn es fest in Serendipity integriert wäre, fände ich besser.

Was ich auch ändern würde wäre, dass die Titel (Blogtitel, Nachrichtentitel) bereits HTML-Codiert an Smarty übergeben werden. Das heißt alle htmlspecialchars() raus. Das "escape" der Daten findet meiner Meinung nach in der View-Schicht statt, also im Smarty-Template selbst. Was sagen die Template-Designer dazu?

Und nun eine Idee:

Kann man sich irgendwie von Smarty komplett loslösen? Auch wenn es Beispiel-Templates gibt, die reines PHP oder XML erzeugen, ist Serendipity trotzdem intern auf Smarty angewiesen. Ich finde diese Template-Engine unterdessen mehr als überholt und arbeite schon einige Zeit mit purem HTML/PHP. Außerdem wird so die Möglichkeit genommen, andere Template-Engines einzusetzen. Ich denke hier an softwareübergreifende Templates. Derzeit ist man mehr oder weniger gezwungen, sein Template nochmal in Smarty zu entwickeln, um eine saubere Lösung zu haben.

Was haltet ihr von Vorschlag eins und zwei und evtl. Vorschlag drei?

Grüße aus DD,

Falk

[garvinhicking]

Hi Falk!

Willkommen zurück in unserem bescheidenen Exil. *g*

Ich wäre dafür, Vor- und Nachname der Blog-Nutzer in getrennten Feldern zu speichern. Das würde es. bspw. vereinfachen, eine Datenbank mit anderen CMS/Foren/Wasweißich zu teilen, die Vor- und Nachnamen getrennt verlangen. Vielleicht könnte man diese Funktion über ein Plugin nachrüsten, aber wenn es fest in Serendipity integriert wäre, fände ich besser.

Es gäbe da tatsächlich zwei Ansätze. Einmal die s9y authors Tabelle zu aktualisieren, dann hab man aber womöglich Probleme mit der migration bestehender Benutzernamen.

Die andere Variante wäre die Daten separat in der serendipity_Config zu speichern, da nach authorid zugeordnet. Eigentlich genauso wie das userprofiles-Plugin.

Was ich auch ändern würde wäre, dass die Titel (Blogtitel, Nachrichtentitel) bereits HTML-Codiert an Smarty übergeben werden. Das heißt alle htmlspecialchars() raus. Das "escape" der Daten findet meiner Meinung nach in der View-Schicht statt, also im Smarty-Template selbst. Was sagen die Template-Designer dazu?

Ganz im Gegenteil, ich finde htmlspecialchars gehört definitiv IN die View, denn es gibt durchaus reale Fälle in denen man die Daten unescaped braucht.

Kann man sich irgendwie von Smarty komplett loslösen?

Man könnte, durch die von Dir erwähnten Beispieltemplates. Aber irgendeine API braucht man für Templates ja, und warum was eigenes brauen? Smarty ist wirklich toll, und die Nutzer kennen es auch. Zumindest s9y user würden fluchen wenn man eine andere templateengine promoten würde und in den vordergrund stellen.

Die smarty API ist ja so toll dass sie problemlos durch andere APIs mit Connectoren eingesetzt werden kann. Sind ja nur ein handvoller Befehle.

Zudem kann man ja auch in smarty templates einfach PHP nutzen um existierende Templates anderer Systeme einzubinden...

Grüße,
Garvin

[falk]

Hi Falk!

Willkommen zurück in unserem bescheidenen Exil. *g*

Ist lange her ... ich muss mich inzwischen rasieren .

Ich wäre dafür, Vor- und Nachname der Blog-Nutzer in getrennten Feldern zu speichern. Das würde es. bspw. vereinfachen, eine Datenbank mit anderen CMS/Foren/Wasweißich zu teilen, die Vor- und Nachnamen getrennt verlangen. Vielleicht könnte man diese Funktion über ein Plugin nachrüsten, aber wenn es fest in Serendipity integriert wäre, fände ich besser.

Es gäbe da tatsächlich zwei Ansätze. Einmal die s9y authors Tabelle zu aktualisieren, dann hab man aber womöglich Probleme mit der migration bestehender Benutzernamen.

Was wären das für Probleme? Das jetzige Feld würde ich für den Nachnamen nutzen, also nur noch ein Feld für den Vornamen hinzufügen.

Die andere Variante wäre die Daten separat in der serendipity_Config zu speichern, da nach authorid zugeordnet. Eigentlich genauso wie das userprofiles-Plugin.

Die Lösung gefällt mir ehrlich gesagt nicht so gut. Das hat was von Frickeln.

Was ich auch ändern würde wäre, dass die Titel (Blogtitel, Nachrichtentitel) bereits HTML-Codiert an Smarty übergeben werden. Das heißt alle htmlspecialchars() raus. Das "escape" der Daten findet meiner Meinung nach in der View-Schicht statt, also im Smarty-Template selbst. Was sagen die Template-Designer dazu?

Ganz im Gegenteil, ich finde htmlspecialchars gehört definitiv IN die View, denn es gibt durchaus reale Fälle in denen man die Daten unescaped braucht.

Ups, da haben wir uns falsch verstanden. Ich bin dafür das Escapen in den View zu verlegen. Und da du das auch bist, stelle ich das mal als Bugreport hier rein. Denn derzeit werden die Überschriften und die Blogbeschreibung vor der Übergabe an Smarty durch htmlspecialchar geschoben.

Kann man sich irgendwie von Smarty komplett loslösen?

Man könnte, durch die von Dir erwähnten Beispieltemplates. Aber irgendeine API braucht man für Templates ja, und warum was eigenes brauen? Smarty ist wirklich toll, und die Nutzer kennen es auch. Zumindest s9y user würden fluchen wenn man eine andere templateengine promoten würde und in den vordergrund stellen.

Die smarty API ist ja so toll dass sie problemlos durch andere APIs mit Connectoren eingesetzt werden kann. Sind ja nur ein handvoller Befehle.

Zudem kann man ja auch in smarty templates einfach PHP nutzen um existierende Templates anderer Systeme einzubinden...

Na ja, dieser Meinung bin ich nicht. Aber ich denke ich kann mich wieder mit Smarty anfreunden. Ich habe jetzt viel mit Zend_View und den Helpern gearbeitet und da finde ich Smarty als vergleich etwas sehr ... eigenartig. Andererseits, vor einigen Jahren gings ja auch.

Grüße,
Garvin

Ich grüße zurück.

[garvinhicking]

Hi!

Was wären das für Probleme? Das jetzige Feld würde ich für den Nachnamen nutzen, also nur noch ein Feld für den Vornamen hinzufügen.

Ja, aber alle Templates benutzen bisher nur den Autorennamen, d.h. es müssten dann auch alle Themes angepackt werden. Da wäre ich also evtl eher dafür den vollen Namen beizubehalten und zuästzlich Vorname + Nachname einzugeben, damit es hier nicht mal zu Konflikten mit Templates kommt. Und ich glaube ich wäre dann eher für die Pluginlösung. Die Autorendaten würden ja dann sowieso in $serendipity zum auslesen durch alle templates populiert.

Die andere Variante wäre die Daten separat in der serendipity_Config zu speichern, da nach authorid zugeordnet. Eigentlich genauso wie das userprofiles-Plugin.

Die Lösung gefällt mir ehrlich gesagt nicht so gut. Das hat was von Frickeln.

Hm, also es ist halt quasi ein denormalisierter Datenstoragepunkt für grundlegende Metadaten. Gerade bei erweiterbaren Systemen hat es sich nicht bewährt, für alles eigene Spalten anzulegen sondern eher "vertikal" zu abstrahieren. Bei den entryproperties, den plugin configs und generell "named metadata" ist das eigentlich ein guter Ansatz. Denn dann muss man später keine Tabelle erweitern, nur weil ein neuer Schlüssel dazu kommt. Am liebsten hätte ich im nachhinein dann s9y komplett so aufgezogen, dass sämtliche metadaten abstrahiert vorliegen. Etwas so wie "elgg", damit habe ich gerade viel Spaß.

Ups, da haben wir uns falsch verstanden. Ich bin dafür das Escapen in den View zu verlegen. Und da du das auch bist, stelle ich das mal als Bugreport hier rein. Denn derzeit werden die Überschriften und die Blogbeschreibung vor der Übergabe an Smarty durch htmlspecialchar geschoben.

Ah, alles klar - da habe ich an dir vorbeigeredet. Hm, auch hier ist dann das problem dass dann erstmal alle älteren und vor allem EIGENE templates sicherheitsprobleme kriegen könnten, wenn die entities auf einmal durchgereicht werden, was sie vorher nicht wurden. Aber das htmlspecialchars() hinzufügen dürfte von s9y ja nur bei ganz wenigen Fällen tatsächlich vorliegen...

Na ja, dieser Meinung bin ich nicht. Aber ich denke ich kann mich wieder mit Smarty anfreunden. Ich habe jetzt viel mit Zend_View und den Helpern gearbeitet und da finde ich Smarty als vergleich etwas sehr ... eigenartig. Andererseits, vor einigen Jahren gings ja auch.

Hehe, ich denke da stehen wir gerade an ganz anderen Ufern. Ich konnte mich mit Zend nie wirklich anfreunden, empfand das alles sehr bloated und unnötig verschachtelt.

Viele Grüße,
Garvin

[falk]

Ja, aber alle Templates benutzen bisher nur den Autorennamen, d.h. es müssten dann auch alle Themes angepackt werden. Da wäre ich also evtl eher dafür den vollen Namen beizubehalten und zuästzlich Vorname + Nachname einzugeben, damit es hier nicht mal zu Konflikten mit Templates kommt. Und ich glaube ich wäre dann eher für die Pluginlösung. Die Autorendaten würden ja dann sowieso in $serendipity zum auslesen durch alle templates populiert.

Dann müssten aber wieder drei Felder gefüllt werden: Kompletter Name, Vorname und Nachname.

Hm, also es ist halt quasi ein denormalisierter Datenstoragepunkt für grundlegende Metadaten. Gerade bei erweiterbaren Systemen hat es sich nicht bewährt, für alles eigene Spalten anzulegen sondern eher "vertikal" zu abstrahieren. Bei den entryproperties, den plugin configs und generell "named metadata" ist das eigentlich ein guter Ansatz. Denn dann muss man später keine Tabelle erweitern, nur weil ein neuer Schlüssel dazu kommt. Am liebsten hätte ich im nachhinein dann s9y komplett so aufgezogen, dass sämtliche metadaten abstrahiert vorliegen. Etwas so wie "elgg", damit habe ich gerade viel Spaß.

Ob man Daten vertikal oder horizontal speichert kommt auf die Größe der Anwendung an. Bei einem Blog mit 5 Nutzern stimme ich dir zu, aber bei einem Portal ist es performanter eine Spalte hinzuzufügen. Und mein letztes größeres Projekt ist mehr in die Kategorie Portal einzuordnen. Deshalb habe ich lieber eine Spalte mehr in der Tabelle als dass ich mir 200 Datensätze aus einer Tabelle zum passenden User raussuchen muss.

Elgg? Ja, viel Spaß hatte ich auch als ich das sah:

Code: Select all

require_once(dirname(dirname(dirname(dirname(__FILE__)))) . "/engine/start.php");

Ah, alles klar - da habe ich an dir vorbeigeredet. Hm, auch hier ist dann das problem dass dann erstmal alle älteren und vor allem EIGENE templates sicherheitsprobleme kriegen könnten, wenn die entities auf einmal durchgereicht werden, was sie vorher nicht wurden. Aber das htmlspecialchars() hinzufügen dürfte von s9y ja nur bei ganz wenigen Fällen tatsächlich vorliegen...

Ich habe mir mit dem htmlspecialchar bereits ins Bein geschossen, was die View-Schicht angeht. Aber da es sich um eine 1.5 und nicht um eine 1.4.x handelt, würde ich schon sagen, die User sollten sich mit dieser kleinen Änderung anfreunden können. Schließlich ist es keine API-Änderung, bei der alle Plugins neugeschrieben werden müssen. Außerdem wird es eh ein neues Template geben. (Da kann man auch mal sehen, wer alles schön die README.TXT ließt .)

Hehe, ich denke da stehen wir gerade an ganz anderen Ufern. Ich konnte mich mit Zend nie wirklich anfreunden, empfand das alles sehr bloated und unnötig verschachtelt.

Ich habe keine Lust mit dir über das ZendFramework zu streiten .

[WMK]

<senf>
ich hab viel mit pear::html_flexy gearbeitet. Das schiebt automatisch JEDE Variable durch html_specialchars, man kann es aber mit {variable:h} abschalten, wenn man wirklich das HTML ausgeben will.

Flexy wurde deswegen auch mal das "Kondom" der Template Engines genannt.

Inwieweit es Sinn macht, das Escapen innerhalb s9y zu automatisieren, weis ich nicht. Aber vielleicht ist mein Senf als Anregung brauchbar.
</senf>

[falk]

<senf>
ich hab viel mit pear::html_flexy gearbeitet. Das schiebt automatisch JEDE Variable durch html_specialchars, man kann es aber mit {variable:h} abschalten, wenn man wirklich das HTML ausgeben will.

Flexy wurde deswegen auch mal das "Kondom" der Template Engines genannt.

Inwieweit es Sinn macht, das Escapen innerhalb s9y zu automatisieren, weis ich nicht. Aber vielleicht ist mein Senf als Anregung brauchbar.
</senf>

Dein Senf ist nicht ganz verkehrt. Das heißt, wenn ich jetzt anfange mit basteln und Html_Flex als Template-Engine einsetze, werde die Daten zwei Mal escapet. Noch ein Grund mehr, für die Änderung zu sein.

[garvinhicking]

Hi!

Also auf das htmlspecialchars() im php core zu entfernen würde ich mich wohl einlassen, bei blogtitel und blogdescription wäre es ja evtl auch wirklich wünschenswert, HTML Code auszugeben. Das habe ich mal in den 1.5 tree committed.

Ja, aber alle Templates benutzen bisher nur den Autorennamen, d.h. es müssten dann auch alle Themes angepackt werden. Da wäre ich also evtl eher dafür den vollen Namen beizubehalten und zuästzlich Vorname + Nachname einzugeben, damit es hier nicht mal zu Konflikten mit Templates kommt. Und ich glaube ich wäre dann eher für die Pluginlösung. Die Autorendaten würden ja dann sowieso in $serendipity zum auslesen durch alle templates populiert.

Dann müssten aber wieder drei Felder gefüllt werden: Kompletter Name, Vorname und Nachname.

Ja, aber dafür wäre es halt am saubersten mit alten Templates zu integrieren.

Ob man Daten vertikal oder horizontal speichert kommt auf die Größe der Anwendung an. Bei einem Blog mit 5 Nutzern stimme ich dir zu, aber bei einem Portal ist es performanter eine Spalte hinzuzufügen. Und mein letztes größeres Projekt ist mehr in die Kategorie Portal einzuordnen. Deshalb habe ich lieber eine Spalte mehr in der Tabelle als dass ich mir 200 Datensätze aus einer Tabelle zum passenden User raussuchen muss.

Das wäre mal interessant zu benchmarken. Wenn man einen unique key auf Spalten (id, metaname) anlegt dürfte es garnicht so viel langsamer sein. Etwas verändert sich das handling natürlich zum komplexeren, das seh ich ein. Aber dafür hat es natürlich viel mehr Erweiterungspotential - gerade bei einem pluginbasierten system wie s9y, das ja nicht einfach nur normale redakteure verwalten will sondern ggf. noch viel mehr aufsetzen möchte.

Elgg? Ja, viel Spaß hatte ich auch als ich das sah:

Code: Select all

require_once(dirname(dirname(dirname(dirname(__FILE__)))) . "/engine/start.php");

Hihi. Das war auch so ungefähr mein Gedanke. Die offizielle Meinung dazu ist, dass man so "../../" umgehen will, das wiederum bei symbolischen links probleme machen könnte. Mit dem dirname() sorgt man dafür tatsächliche directories wiederzukriegen. Da dies immer die erste Zeile von plugins etc. ist und sonst noch kein Kern instanziert wurde, ist die Zeile notwendig; lösen könnte man das wohl nur mit prepend files und .htaccess. Aber trotz kleinerer Macken hat Elgg wirklich flexible möglichkeiten für communities.

Ich habe keine Lust mit dir über das ZendFramework zu streiten .

Zum Glück -- was ich damit sagen wolltE: Jeder hat so seine Favoriten, und man kanns nie jedem recht machen bei der Wahl von Frameworks/Templateengines.

grüße,
Garvin

[falk]

Also auf das htmlspecialchars() im php core zu entfernen würde ich mich wohl einlassen, bei blogtitel und blogdescription wäre es ja evtl auch wirklich wünschenswert, HTML Code auszugeben. Das habe ich mal in den 1.5 tree committed.

Ich werde es gleich heute Abend ausprobieren. Mein Template wird sich freuen. Danke.

Dann müssten aber wieder drei Felder gefüllt werden: Kompletter Name, Vorname und Nachname.

Ja, aber dafür wäre es halt am saubersten mit alten Templates zu integrieren.

Das wird dann wie mit der Gruppenverwaltung. Die alte Gruppenverwaltung ist noch da, sollte aber nicht mehr genutzt werden. Bei den Namen: Das alte Feld "Voller Name" ist noch da, sollte aber nicht mehr genutzt werden.

Hihi. Das war auch so ungefähr mein Gedanke. Die offizielle Meinung dazu ist, dass man so "../../" umgehen will, das wiederum bei symbolischen links probleme machen könnte. Mit dem dirname() sorgt man dafür tatsächliche directories wiederzukriegen. Da dies immer die erste Zeile von plugins etc. ist und sonst noch kein Kern instanziert wurde, ist die Zeile notwendig; lösen könnte man das wohl nur mit prepend files und .htaccess. Aber trotz kleinerer Macken hat Elgg wirklich flexible möglichkeiten für communities.

Sowas kann man einwandfrei über das Setzen des Include-Path lösen. Das ist auch ein Thema in S9y, zu dem ich noch eine passende Lösung suche. Spart viel Tipparbeit und ist sauberer wenn es um das Wechseln von Komponenten geht. Ob das der nächste Missionierungsversuch wird?

So, das waren meine morgendlichen 2 Cent

Grüßchen,

Falk


Nachtrag: Ich habe das mit den htmlspecialchars ausprobiert und bin zufrieden! So habe ich es mir vorgestellt.

[stm999999999]

Themes angepackt werden. Da wäre ich also evtl eher dafür den vollen Namen beizubehalten und zuästzlich Vorname + Nachname einzugeben, damit es hier nicht mal zu Konflikten mit Templates

Dann müssten aber wieder drei Felder gefüllt werden: Kompletter Name, Vorname und Nachname.

hm, was wäre denn damit:

neu einführen:

authors.surname
authors.first_name

das alte authors.realname als Feld löschen! Und für die Update-Migration den Inhalt in authors.surname kopieren.

Und dann aber wegen der Kompatibilität virtuell während der Laufzeit realname als first_name + surname erstellen.

Damit würden alte, unveränderte Templates weiter laufen, aber wir hätten keine Information doppelt im System, die sich ja sogar widersprechen könnten!


Und bei der Gelegenheit mal entries.author rausschmeißen, die Info ist ebenfalls doppelt und bereits in der authors-table vorhanden. Die Info wird ja nicht mal aktualisiert, wenn entweder Autorenname geändert wird, oder ein anderer Autor zugewiesen wird.

[garvinhicking]

Hi!

Würde ich ungerne machen, weil ich weiß dass es einige plugins und auch fremde applikationen gibt, die fest auf die serendipity_authors.realname Tabelle zugreifen. Je länger ich drüber nachdenke, desto sinnvoller sehe ich eine ergänzung der felder innerhalb der serendipity_config. Beim update kann man ja auch realname dynamisch auf die beiden neuen felder aufteilen, und somit verhindern dass user standardmäßig beides eingeben. GGf. ist es ja auch interessant für die Lute, die ihren vollen namen in den namensfeldern eintragen wollen und im "Realname" aber dennoch eine verkürzte Version zeigen wollen.

Beispiel: Jemand heißt Chrysztiano Wienowitschodideskohassobratz. Der wird seinen Namen so evtl nicht unter allen Blogeinträgen habenw ollen. Als loginname nutzt er "chw", weil das keiner kennen soll. Sein im Blog dargestellter Name ist "Chris", weil die Leute ihn so abkürzen. Aber Vorname und Nachname ist voll ausgefüllt, um z.b. in Profilplugins dargestellt zu werden, oder im Backend als Loginbegrüßung.

Vorteile:

- Kompatibel zu alten Themes
- Kompatibel zu externen plugins (weil optional)
- Kein DB-Upgrade notwendig
- Größere Flexibilität bei der Namensvergabe

Einziger Nachteil aus meiner Sicht ist das User die "normal" heißen, ihren Namen evtl zweimal eingeben, oder Vorname/Nachname bei der installation nicht ausfüllen werden/wollen.

Und bei der Gelegenheit mal entries.author rausschmeißen, die Info ist ebenfalls doppelt und bereits in der authors-table vorhanden. Die Info wird ja nicht mal aktualisiert, wenn entweder Autorenname geändert wird, oder ein anderer Autor zugewiesen wird.

Da müsste ich mich nochmal einlesen. die 'authors' Sache ist für ein paar externe Plugins benötigt, die müsste man dann alle durchkämmen.

Grüße,
Garvin

[stm999999999]

Würde ich ungerne machen, weil ich weiß dass es einige plugins und auch fremde applikationen gibt, die fest auf die serendipity_authors.realname Tabelle zugreifen.

lesend oder schreibend?

Wenn nur Lesend, dann vielleicht so:

Im normalen s9y-Backend nur noch die beiden neuen Felder benutzen / anzeigen. Beim Abspeichern .realname entsprechend aus den beiden Feldern zusammensetzen und zusätzlich abspeichern.

Oder, um Deine Idee mit dem gezielt unterschiedlichen Einträgen aufzugreifen:

das .realname-Feld doch anzeigen, aber ausgegraut - dynamisch via JS dann aus den anderen beiden Feldern zusammensetzen und abspeichern - siehe oben. Und dann ein Feld ausgeben, wo man "Realname eigenhändig vergeben" anklicken kann, via JS dann das Feld freigeben.


Virtuelle, errechnete Felder gibt es in (my)sql wohl nicht, oder?

Und bei der Gelegenheit mal entries.author rausschmeißen, die Info ist ebenfalls doppelt und bereits in der authors-table vorhanden. Die Info wird ja nicht mal aktualisiert, wenn entweder Autorenname geändert wird, oder ein anderer Autor zugewiesen wird.

Da müsste ich mich nochmal einlesen. die 'authors' Sache ist für ein paar externe Plugins benötigt, die müsste man dann alle durchkämmen.

Wenn dem so sein sollte, dann haben wir schon jetzt das Problem, daß diese Plugins falsche/veraltete Informationen ausgeben.

[falk]

Hallo ihr beiden,

das nimmt ja langsam interessante Ausmaße an. Javascript, und Feld ausgrauen. Und ich wollte doch nur ein weiteres Feld um Vor- und Nachname getrennt abzuspeichern. Garvins Idee mit dem langen und dem kurzen Namen hat aber auch was für sich.

Aber da sind wir eigentlich schon beim nächsten Thema, was Stephan direkt angesprochen hat: Serendipity ausmisten. Da ist ja noch Kompatibilität aus PHP 3.0 drin (zumindest habe ich so den Eindruck). Kann man da nicht langsam mal ausmisten und sagen: He, Leute, PHP 5.3 ist schon raus (ich will nicht dass S9y nur noch mit PHP 5.3 läuft, aber wie ihr wisst ist mir die PHP4-Kompatibilität schon eine Weile ein Dorn im Auge). Vieles geht ganz schön auf die Performance. Ich sehe hier die vielen "define" und die !function_exists(), auch $HTTP_POST oder wie das hieß.

Gut, wir schweifen zu weit ab. Also zum Thema: Ich will meine Felder für Vor- und Nachname. Und ich bevorzuge eine horizontale Lösung (was das Datenbankdesign angeht).

[stm999999999]

das nimmt ja langsam interessante Ausmaße an. Javascript, und Feld ausgrauen. Und ich wollte doch nur ...

[yellowled]

Kann man sich irgendwie von Smarty komplett loslösen?

Man könnte, durch die von Dir erwähnten Beispieltemplates. Aber irgendeine API braucht man für Templates ja, und warum was eigenes brauen? Smarty ist wirklich toll, und die Nutzer kennen es auch. Zumindest s9y user würden fluchen wenn man eine andere templateengine promoten würde und in den vordergrund stellen.

Allerdings

Allerdings lese ich gerade im Webstandardsmagazin, dass ab PHP5 ohnehin eine Art Nachfolger von Smarty names Dwoo die standardmäßige Templateengine von PHP sein soll. Das liest sich (für mich als bestenfalls Halbexperten) ziemlich sexy und abwärtskompatibel. Und der komplette Sprung zu PHP5 wird ja anscheinend irgendwann[tm] auch nicht zu vermeiden sein ..?

YL