QUOTE (carapau @ Fr 8.01.2010, 22:11)Kannst du konkrete Frameworks nennen?
Ich arbeite seit langem (seit 2003) mit .NET.
Damit können sowohl Webanwendungen (auf der Basis ASP.NET) als auch zusätzliche Dienste, mit denen die Webanwendung kommunizieren kann, bereitgestellt werden.
Bestimmte zusätzliche Caching-Dienste (nicht das Caching innerhalb der Webanwendung, sondern das Caching bestimmter Werte, die sonst jedesmal aus der Datenbank gelesen werden müßten) oder zusätzliche Dienste wie eine PDF-Generierung lassen sich so in eigene Prozesse auslagern. Bei Bedarf könnte man das sogar auf eigenen Servern laufen lassen (ist aber aktuell nicht notwendig).
QUOTE (steffi @ Fr 8.01.2010, 22:35)
QUOTE (Jürgen Auer @ Fr 8.01.2010, 21:44) Template-Engines sind für mich Level 1995.
Wer das verwendet, der arbeitet m.E. nach in der Web-Steinzeit.
Template-Engines sind etwas wunderbares.
Du scheinst noch nie in einem mehrköpfigem Team von Designern & Programmieren an einem Projekt gleichzeitig gearbeitet zu haben. Level 1995
Wenn ich Wikipedia zitieren darf:
QUOTE Eine Template Engine (von engl. Vorlage und Antrieb, Motor) ist eine Software, die eine Datei (das Template) verarbeitet, und bestimmte Platzhalter darin mit jeweils aktuellen Inhalten füllt.
Du scheinst noch nie mit Xml-Fragmenten und massiven Xslt-Dateien gearbeitet zu haben.
Bei einer klassischen Template Engine kann der Platzhalter einmalig durch Inhalt ersetzt werden. Was ist aber, wenn der Inhalt des Platzhalters selbst Platzhalter enthält, Du also ein rekursives Durchlaufen benötigst, bei dem jetzt völlig unbekannt ist, wieviele Durchläufe übermorgen benötigt werden.
So etwas manuell programmieren zu wollen, ist absurd. Xslt leistet das 'von ganz alleine' - seit 2001. Die ganze Konzeption von Xslt wurde ja u.a. gerade entwickelt, weil sich ein einfaches Suchen-Ersetzen (wie es ab etwa 1995 im Web möglich war) als 'viel zu wenig' herausstellte.
Das weitaus dramatischere Problem ist, daß man bei solchen Template-Engines ständig den PHP-Code anpassen muß, der die Templates verarbeitet.
Bei Xml/Xsl-Strukturen kann man im Normalfall darauf komplett verzichten, da an der Xslt-Datei nur selten Änderungen notwendig sind.
Wenn ich das Wiki-Beispiel zitiere:
Template:
QUOTE <body> <p>{NAME}</p> </body>
PHP
QUOTE $template->assign('NAME', 'Erika Mustermann'
;
Das sind individuelle Sprachen und individuelle Parser. So hat man in den 80-ern und 90-ern gearbeitet. Einer der Entwicklungsschübe, die durch das Web ausgelöst wurden, lief gerade darauf hinaus, sich von solchen 'Individualparsern' zu verabschieden.
Stattdessen etwas wie:
CODE <table>
<tr><th>Spalte1</th><th>Spalte2</th></tr>
<sd:rs sd:source-name='v_Artikel'>
<sd:normal>
<tr>
<td><sd:cell-value sd:col='ArtikelId'/></td>
<td><sd:cell-value sd:col='Artikelname'/></td>
</tr>
</sd:normal>
<sd:alternate>
<tr class='second-row'>
...
</tr>
</sd:alternate>
</sd:rs>
</table>
Aufgrund der rekursiven Auflösung kann überall zusätzlicher Html-Code drinstehen. Ferner können solche Fragmente selbst ausgelagert werden und von verschiedensten Stellen her genutzt werden. Die reine Xslt-Transformationszeit liegt selbst bei Seiten, die gesamte Designs (mit diversen solcher Fragmenten aus verschiedenen Tabellen) enthalten, im Bereich von 0,01 Sekunden.
Da können sich Designer völlig auf das Design konzentrieren.
