> > > Aber wie dann das ganze HTML-Gedöns verwalten? In einer separaten Klasse? > > Die an den Request URI gebundene Klasse qualifiziert die Herkunft des Templates. Als API kommen IO/File, DAL oder print/echo in Frage. > Ich kenne übrigens einige Unternehmen, die das so machen. In einer mod_perl Umgebung beispielsweise ist der Apache-ResponseHandler die Superklasse und bei jedem Request wird eine Instanz einer Subklasse erstellt (Vererbung). Die Templates liegen permanent im Hauptspeicher für den wahlfreien Zugriff. Die Instanz der Subklasse befüllt lediglich einen Hash mit Platzhaltern wobei die Validierung in der Subklasse stattfindet. Dem Cleanup-Prozess kommt eine besondere Bedeutung zu, er muss dafür sorgen, dass Benutzerdaten aus dem Hauptspeicher verschwinden und ggf. persistent für eine Session sind. Hier zeigt sich die Zweckmäßigkeit eines Klassendesigns überhaupt. Schöne Grüße

> > > Aber wie dann das ganze HTML-Gedöns verwalten? In einer separaten Klasse? > > Die an den Request URI gebundene Klasse qualifiziert die Herkunft des Templates. Als API kommen IO/File, DAL oder print/echo in Frage. > Ich kenne übrigens einige Unternehmen, die das so machen. In einer mod_perl Umgebung beispielsweise ist der Apache-ResponseHandler die Superklasse und bei jedem Request wird eine Instanz einer Subklasse erstellt (Vererbung). Die Templates liegen permanent im Hauptspeicher für den wahlfreien Zugriff. Die Instanz der Subklasse befüllt lediglich einen Hash mit Platzhaltern wobei die Validierung in der Subklasse stattfindet. Dem Cleanup-Prozess kommt eine besondere Bedeutung zu, er muss dafür sorgen, dass Benutzerdaten aus dem Hauptspeicher verschwinden und ggf. persistent für eine Session sind. Hier zeigt sich die Zweckmäßigkeit eines Klassendesigns überhaupt. Schöne Grüße -- Willy Brandt: Wir haben keine Demokratie solange unser Grundgesetz ein Diktat der Amerikaner ist.