nicht angemeldet
Was sollte eine Klasse alles können?
Hi alle,
Ich habe sehr selten Klassen gesehen, die auch HTML erzeugen. Ist das schlechte Praxis? Bei einer Login-Klasse z.B. würde es doch Sinn machen, da die HMTL-Elemente im grunde ja immer gleich bleiben. Ein Formular, 2 - 3 input-Elemente, ein radio-Element und ein Submit. Es wäre ja an sich kein Problem, das zu trennen. Aber wenn alles zusammen bleibt, wäre die implementiereung doch viel einfacher.
Oder wenn ich bspw. eine Klasse schreibe, die eine Linkliste erzeugt (Navigation od. ähnliches). Sollte so eine Klasse die Liste direkt als HTML-Liste erzeugen, oder eher ein Array/Objekt erzeugen, was wiederum ausserhalb der Klasse zu einer HTML-Liste zusammengesetzt wird? Hier würde mir die Array-Methode eher zusagen, da ich so die Ausgabe komplett Variabel steuern könnte, ohne in die Klasse eingreifen zu müssen. Sollte eine Klasse also im Grunde nur Werte und Ergebnisse liefern, und das HTML von aussen drumherum gepackt werden? Wenn ich das so lese, ist die Antwort klar: Ja. Aber wie dann das ganze HTML-Gedöns verwalten? In einer separaten Klasse? Aber dann wären ja wieder abhängigkeiten zu anderen Klassen gegeben? Oder sind abhängigkeiten eher Normal?
Bis bald
--
Hosen sind Blau
Hosen sind Blau
-
Tach!
Ich habe sehr selten Klassen gesehen, die auch HTML erzeugen. Ist das schlechte Praxis?
Das kann man so pauschal nicht sagen. Es gibt durchaus Systeme, die die Ausgabe im Code erzeugen, statt Templates zu verwenden.
Bei einer Login-Klasse z.B. würde es doch Sinn machen, da die HMTL-Elemente im grunde ja immer gleich bleiben. Ein Formular, 2 - 3 input-Elemente, ein radio-Element und ein Submit.
Das sagst du so einfach. Aber dann kommt schnell hinzu, dass da noch für die Validierung und die Anzeige der Ergebnisse Elemente hinzukommen.
Es wäre ja an sich kein Problem, das zu trennen. Aber wenn alles zusammen bleibt, wäre die implementiereung doch viel einfacher.
Letzten Endes ist es einfacher, wenn man sich nicht zu sehr einengt. Die Login-Klasse braucht nur die Daten. Woher sie die bekommt, kann ihr vollkommen egal sein. Deshalb sollte diese Klasse sich nicht mit dem HTML-Krams rumschlagen müssen. Das Einloggen ist schon Aufgabe genug für sie.
Der HTML-Kram kommt ins Template. Und da kann es durchaus nützlich sein, wenn ein Helper oder ein Subtemplate das komplexe Element "Loginformular" rendert.
dedlfix.
-
Hi dedlfix,
Ich habe sehr selten Klassen gesehen, die auch HTML erzeugen. Ist das schlechte Praxis?
Das kann man so pauschal nicht sagen. Es gibt durchaus Systeme, die die Ausgabe im Code erzeugen, statt Templates zu verwenden.Stimmt wohl, soviele habe ich auch noch garnicht gesehen.
Das sagst du so einfach. Aber dann kommt schnell hinzu, dass da noch für die Validierung und die Anzeige der Ergebnisse Elemente hinzukommen.
Die validierung der Daten müsste doch ohnehin in der Klasse geschehen, oder verstehe ich dich falsch? Du meinst wohl, wie ich die Rückgabewerte im HTML ausgebe?
Letzten Endes ist es einfacher, wenn man sich nicht zu sehr einengt. Die Login-Klasse braucht nur die Daten. Woher sie die bekommt, kann ihr vollkommen egal sein. Deshalb sollte diese Klasse sich nicht mit dem HTML-Krams rumschlagen müssen. Das Einloggen ist schon Aufgabe genug für sie.
Stimmt, sieht auch übersichtlicher aus. Das HTML-Zeugs macht mehr als 50 - 60 % der Klasse aus.
Der HTML-Kram kommt ins Template. Und da kann es durchaus nützlich sein, wenn ein Helper oder ein Subtemplate das komplexe Element "Loginformular" rendert.
Subtemplate klingt gut, damit werde ich's wohl machen.
Bis bald
--
Hosen sind Blau-
Tach!
Das sagst du so einfach. Aber dann kommt schnell hinzu, dass da noch für die Validierung und die Anzeige der Ergebnisse Elemente hinzukommen.
Die Validierung der Daten müsste doch ohnehin in der Klasse geschehen, oder verstehe ich dich falsch? Du meinst wohl, wie ich die Rückgabewerte im HTML ausgebe?
Die Validierung selbst kommt natürlich in die Nähe der Daten(verarbeitung). Die kann Bestandteil der Klasse sein oder auch separat. Ich meinte mit dem Satz die Ausgabe der Validierungsergebnisse. Dazu sind üblicherweise Elemente im HTML notwendig.
dedlfix.
-
-
-
hi,
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.
Aber dann wären ja wieder abhängigkeiten zu anderen Klassen gegeben? Oder sind abhängigkeiten eher Normal?
So wenig wie möglich, so viel wie nötige Abhängigkeiten. Sag I. Der DAL (Data Access Layer) z.B. kann einfach nur eine Methode sein die von einer beliebigen Instanz (Mocking) aufgerufen werden kann und als Argument bspw. nur den Dateinamen oder eine ID übergeben kriecht.
--
-
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
-