mit grossem interesse hab ich eure diskussion gelesen. ich selbst hab ein eigenes php basiertes cms programmiert, welches frame oder nonframe basierte auftritte modular aufbauen kann.
meine erfahrungen der letzten 6 jahre in diesem bereich gehen dahin, dass für den "endkunden" das system letztlich unerheblich ist welches zum einsatz kommt. sicher spielen performance faktoren eine rolle, aber ich meine von der technischen sicht aus.
was bleibt sind die anforderungen der personen die den auftritt realisieren bzw. pflegen und verschiedene kriterien anlegen:
1. falls der "endkunde" am design selbst eine änderung durchführen will muss dies möglichst einfach möglich sein
2. eine trennung von template dateien (in welchem format auch immer) und php script dateien muss schon wegen dem möglichen einsatz vom php optimizer möglich sein
3. falls der "entwickler" und "webdesigner" zwei unterschiedliche personen sind muss die template engine diese "teilung" mitmachen
4. das ganze muss unkompliziert sein um auch nach einigen wochen/monaten/jahren änderungen machen zu können ohne docu studieren zu müssen. das ist auch bei wechselnden zuständigkeiten hilfreich.
um es mal etwas analytischer anzugehen gibt es innerhalb eines webauftritts bestimmte, gleichbleibende bereiche, die immer wieder vorkommen. innerhalb dieser "bereiche" gibt es dann zumeist grosse unterschiede in der art und weise der darstellung. diese unterschiede lassen sich nicht immer alleine durch den einsatz von css lösen (man denke z.b. an eine spezielle navigationsart die wiederum vom design her abgeleitet wird).
aus meiner erfahrung heraus teile ich einen webauftritt in folgende bereiche auf:
1. navigation
2. content
3. teasing
4. sidebar
5. footer
zu 1: die navigation kann von projekt zu projekt sehr unterschiedlich sein. der eine will ein pulldown menu, der andere aufklappende menüpunkte. anforderungen wie "muss auch ohne javascript funktionieren" sind da natürlich auch eingeschlossen. aber auch der einsatz von flash elementen in der navigation muss in betracht gezogen werden können.
zu 2: der inhalt besteht aus texten und bildern, tabellen und sog. bausteinen die je nach projektumfang innerhalb des "contents" verwendet werden sollen.
zu 3: teasing mein elemente die aufgrund des webdesigns eingeführt werden sollen. so soll z.b. pro menüpunkt eine andere grafik eingeblendet werden.
zu 4: mit side meine ich den bereich der auf auftritten mit sehr dynamischen komponenten oder einem "benutzerbereich" informationen einbaut. das können streifen links oder recht vom "content" sein die je nach menüpunkt auch noch unterschiedlich aufgebaut sind. manchmal will der "endkunde" auch einfluss auf die positionierung der dynamischen elemente innerhalb des "sidebar"-bereiches haben (z.b. zuerst die news und dann den veranstaltungskalender usw.).
zu 5: zwar ist die fusszeile zumeist kein grosses thema, aber ich hatte auch schon projekte bei denen ich dankbar war auch diesen bereich noch den anderen gleichgestellt zu haben.
es ist klar das nicht immer alle webprojekte alle diese bereiche benötigen, aber ich sag mal im schnitt kommt es doch sehr häufig vor das es diese braucht. sicher gibt es projekte die noch viel mehr benötigen, aber diese komplexität staffelt sich dann innerhalb eines dieser benannten bereiche.
aus dieser analytischen sicht kann man nun eine lösung für das "parser" problem ableiten. die template engine meines cms z.b. teilt diese aufgabe auf. zwar wird die gesamte site durch einen parser gejagt, der wiederrum führt an den benannten bereichen sozusagen "subparser" aus die bestimmen wie sich der inhalt aufbaut. so ist es z.b. möglich auch komplexe anforderungen zu modularisieren - will heissen in applikationslogik und html bestandteile aufzuteilen.
zur performance: meine feststellung ist, dass auftritt mit viel traffik so oder so irgendwann auf caching umsteigen müssen. somit stellt sich die frage nach der "ausgangsgeschwindigkeit" nicht mehr unbedingt. selbst wenn der neuaufbau durch die php enginge ein paar millisekunden länger braucht macht das im schnitt den breit auch nicht mehr fett wenn dahinter dann gecached ausgeliefert wird.
grosse performancegewinne bzw. verluste erhält derjenige der datenbank-abfragen nicht konsolidiert behandelt und sich nicht mit den eigenheiten von SQL befasst. da steckt eine menge an optimierungspotential drin durch die man sich php code sparen kann.
sicher ist auch meine lösung nicht der letzte schluss, aber ich kann sagen das ich bislang kein projekt hatte das nicht so zu realisieren war. und dabei spielt es, wie bereits anfangs gesagt, letztlich keine rolle wie man es technisch nun anstellt - ob man nun {geschweifte} elemente ins template einsetzt oder <?php code ?> direkt platziert. entscheident ist nur ob man dem kunden zugang zu dieser informationen gewähren will oder nicht und in wie weit fehler entstehen könnten wenn der kunde etwas falsch macht.
zur sicherheit: ein ganz entscheidender faktor ist meiner erfahrung nach, dass man dem "endkunden" und "designer" möglichst keine "programmiersprache" zur verfügung stellt mit der er einfluss auf die applikationslogik hat. das kann dann ein böses erwachen werden wenn da sicherheitslöcher bekannt werden. auch hier muss ich sagen, dass php oder auch andere scriptsprachen wie z.b. perl sich da nicht gross unterscheiden. wenns "" programmiert wurde bringts die sprache dahinter auch nicht mehr.
mehr informationen zu meinem bescheidenen cms gibts unter static2dynamic.de
