nicht angemeldet
Hallo,
Zitat Wikipedia:
Demgegenüber steht der ursprüngliche Gedanke der Template Engines: Sie sollen statischen Text und dynamische Inhalte möglichst effizient miteinander verknüpfen. Oft sind Template Engines deshalb gerade in Programmiersprachen anzutreffen, deren Syntax eine solche Mischung nicht direkt unterstützt: (z.B. Java: JSP; VBScript u.a.: ASP)Für eine echte Trennung der Darstellung von den Datenmodellen und den Logikkomponenten sind Template Engines dagegen ungeeignet und es sind zusätzliche Konzepte wie z.B. MVC notwendig
Zitatendehttp://de.wikipedia.org/wiki/Template_Engine
Ok, das merke ich mittlerweile auch. Demnach kann man diesen Zustand (Trennung von Logik und Ausgabe) nur anpeilen, aber niemals vollständig erreichen.
Verstanden habe ich leider immer noch nicht, was Du mir mit der Auflistung der einzelnen Bestandteile von Programmen (Listenansicht, Detailansicht usw.) sagen willst.
Das gehört für mich dazu, sonst könnte müßte ich wieder Programmlogik und Ausgabe vermischen, entweder im Template selbst oder mittels Zusammenbau der Optionsfelder im Skript selbst.
warum kann man die Optonsfelder nicht im Script zusammenbauen ?
nur das "Programm" weiß doch was da drinstehen muss
»»
Na ja, der Sinn des Templates sollte ja Trennung von Logik und Ausgabe sein. Wenn ich ein Optionspaar männlich/ weiblich habe, das aus einer Datenbank befüllt wird, sind bis auf den Zustand, welches Element aktiviert ist, alle Inhalte statisch. Somit sollten diese statischen Elemente
<input type="radio" name="gender" value="m" ...>männlich
<input type="radio" name="gender" value="f" ...>weiblich
im Template enthalten sein. Die Abfrage, welchen Zustand die Radio-Felder haben, kann man direkt innerhalb des <input>-Tags vornehmen. Das ist nicht sinnvoll. Die <input>-Elemente aus dem Template nehmen ist ebenso sinnlos. Je nachdem, wieviel Content aus dem Template genommen wird, bleibt vom Template nicht viel übrig, womit wir wieder beim Mischmasch aus Logik und Ausgabe sind, diesmal nur an anderer Stelle und auf einer höheren Abstraktionsstufe. Bleibt also nur eine Schnittstelle im Template einzufügen
<input type="radio" name="gender" value="m" ##gender_m##>männlich
<input type="radio" name="gender" value="f" ##gender_f##>weiblich
Das finde ich übersichtlich, es erspart Schreibarbeit unzähliger Vergleiche (statt dessen ein Methodenaufruf $template->radio("gender", "f") ), und der Designer kann seine Vorstellungen innerhalb des Templates verwirklichen.
Wie würdest Du Optionsfelder in Templates verwirklichen?