nicht angemeldet
Hallo,
ich habe mich mißverständlich ausgedrückt. Der Satz "Eine Schablone soll ja dazu dienen, mit genau einer Schablone beliebig viele Seiten zu erstellen." sollte in dem Kontext nicht ausdrücken, daß lediglich eine Schablone angefertigt wird, sondern daß jede Schablone mehrfach verwendbar ist. Das ist der Zweck jeder Schablone. Wenn die Schablone lediglich dazu dienen soll, Logik und Ausgabe zu trennen, finde ich den Begriff nicht passend. Bei Unter- oder Nebenschablonen kann man das auch weniger eng sehen. Wenn es eine Masterschablone gibt, die sich auf (fast) allen Seiten wiederfindet und zusätzliche "Schablonen", die für jede Seite spezifisch angelegt werden, kann man diese Nebenschablonen, die nur ein einziges Mal Verwendung finden, meinetwegen auch als Schablone bezeichnen, auch wenn sie das im eigentlichen Sinn nicht mehr sind.
Im Prinzip habe ich es bisher schon so realisiert, daß es eine Masterschablone gibt und jede Seite eine weitere eigene hat. Das muß nicht so sein, nur bei mir sind bei der betroffenen Site die Seiten alle unterschiedlich, weswegen das nötig war.
Bisher sah ich es erst mal als Problem, wenn sich die Seiten in einzelne Schablonen zersplittern, aber das
Für den Designer hat das durchaus Vorteile, da er sich z.B. auf die Gestaltung des Gästebuches konzentieren kann ohne dabei die Navigationsleiste berücksichtigen zu müssen. Bei der Gestaltung der Masterschablone muss er sich Gedanken darüber machen, wie die Elemente (z.B. Kopf, Navigation und Seiteninhalt) zusammen präsentiert werden sollen, ohne die Gestaltungsprobleme dieser Teile bereits vollständig gelöst zu haben. Natürlich bestehen da Abhängigkeiten, wenn z.B. die Bilder der Bildergalerie in einer Breite präsentiert werden soll, für die die Größe des entsprechenden Elements der Masterschablone nicht ausreicht. Das ist aber bei OOP nicht anders. Beim Zusammenführen von unabhängigen Klassen zu einer komplexeren Struktur muss man ja auch die Eigenschaften, Schnittstellen und Verantwortlichkeiten der einzelnen Klassen berücksichtigen. Trotzdem wird versucht, die Abhängigkeiten der Klassen untereinander zu minimieren, damit der Code leichter durchschaubar und wartbar wird (Änderungen haben weniger Seiteneffekte, sind lokal). Warum sollten solche Prinzipien beim Design von Webseiten nicht auch nützlich sein?
sowie das
Bei wenigen komplexen Schablonen ist ein solcher Änderungsaufwand aber viel größer als bei einer (sinnvollen!) Unterteilung in mehrere kleinere Schablonen. Natürlich kann man das auch übertreiben.
hat mir eine neue Perspektive eröffnet. Aufteilung ist also auch für den Designer gar nicht schlecht.
Der Grund für den Einsatz von Schablonen ist ja nicht, viele Daten damit zu formatieren, denn das könnte man auch mit Code tun, sondern Code, Daten und Formatierung voneinender zu trennen um Änderungen mit möglichst wenig Aufwand (und ohne Programmierkenntnisse) durchführen zu können.
Das klingt mir zu einseitig. Müßte der erste Satz nicht so beginnen "Der Grund für den Einsatz von Schablonen ist ja nicht nur" oder "Der Grund für den Einsatz von Schablonen ist ja nicht primär"?
Wie auch immer, Deine Antwort hat mich schon mal ein ganzes Stück weiter gebracht.