Mailinglisten-Archive |
Hallo Seong, Seong-Min Kang schrieb: > Hallo, > >> Mir geht es beispielsweise nur um die Kernfunktion, also die Trennung >> von >> Anwendungslogik und Präsentation, insbesondere auch mit dem Ziel >> verschiedene Ausgabeformate auf der Präsentationsebene bedienen zu >> können >> (XHTML, WAP, XML, PDF, XML, RTF usw.). Mein Anspruch ist, daß die Lösung >> möglichst effizient und ohne unnötigen Overhead sein soll. Vorstellungen >> wie, der Programmierer braucht sich nicht ums Layout zu kümmern und der >> Designer hat nichts mit der Anwendungslogik zu tun, widersprechen >> einfach meinen praktischen Erfahrungen. > > Ich habe sehr gute Erfahrungen gemacht mit XSLT. Meine gesamte > Logikschicht erstellt DOM Dokumente, die ich dann beliebig mit XSLT > bearbeiten kann. XSL-FO und du hast eigentlich gar keine Probleme mehr > mit Ausgabeformaten. genau! Das ist auch noch ein interessanter Punkt. Sollte man nicht direkt XSLT anstatt einer Template Engine verwenden? Immerhin hätte man damit eine weltweit standardisierte Templatesprache, die nicht an PHP gebunden ist, wie es die von Smarty z.B. ist. Eine Frage, die ich mir dabei allerdings stelle, ist, wie es da mit der Performanz aussieht. PHP muß ja dann auf einen externen Parser zugreifen. Ich habe mich noch nicht damit beschäftigt, ob es da nennenswerte Leistungseinbußen gibt. Hast Du schon mal geguckt, wie schnell es ist, eine dynamische PHP-Seite über ein XSL-Template auszuliefern anstatt über eine PHP-Template Engine? Würde sich soetwas für den Live-Einsatz eignen? Viele Grüße Lutz
php::bar PHP Wiki - Listenarchive