nicht angemeldet
Hi!
Ich habe das ganze System immer mehr von der Seite der Templates aus betrachtet, weil diese ja schließlich und endlich das entscheidende Glied in der Kette sind, welches für die Darstellung/ Ausgabe zuständig ist. Bei der Planung erscheint es mir zumindest auch intuitiver, die möglichen Templates zu planen/ kreieren, als die verschiedenen Action-Controller zu konzipieren.
Du schaust dir die Geschichte von außen an. Ich gehe da lieber der Reihenfolge nach. Da wäre als erstes ein Request. Ohne den, nützt dir das beste Template nichts. Vom MVC ausgehend startet der Request ja nicht gleich ein Template, sondern er landet typischerweise beim Front-Controller, der außer grundlegenden Initialisierungen zu einem bestimmten ActionController routet. Dieser Action-Controller erledigt (oder überwacht zumindest) die eigentliche Aufgabe, die im Hintergrund stattfindet, die Business-Logic (meist Speichern oder Abfragen von Daten). Daraus ergibt sich dann eine Ausgabe.
In deinem Fall scheint mir es so zu sein, dass neben der Hauptausgabe eine Menge "Nebensächlichkeiten" in der Ausgabe zu finden sein sollen. "Oberflächlich" betrachtet werden das mehr oder weniger Kästen sein, die verschiedenen Zwecken dienen: Navigation, Login-Bereich, Werbung, News-Ticker und so weiter. Diese willst du anzunehmenderweise mit den Einzel-Templates abdecken. Es ist nun aber nicht so, dass sich ein Action-Controller um alles kümmern muss. Besser ist es dann, die Teilaufgaben auf einzelne Controller zu verteilen, was dann je Ausgabemodul eine eigene Kombination aus M, V und C ergibt. Es muss dann natürlich einen Koordinator geben, der die einzelnen Action-Controller der benötigten Module abgrast und deren Ergebnis in das grundlegende Seitengerüst einbaut.
Es gibt mehrere Möglichkeiten. Eine andere Möglichkeit wäre deshalb, diese Daten in einem Konfigurationssystem abzulegen.
Ja, aber ...!
Schränkt nicht genau diese Variante die Flexibilität enorm ein, bzw. erhöht den Administrationsaufwand?
Mehr Flexibilität setzt ein Mehr an Möglichkeiten voraus, und diese Möglichkeiten müssen erst einmal geschaffen und gewartet und auch administriert werden. Jedes hinzukommende Feature erhöht insgesamt die Komplexität und den Betriebsaufwand. Die Frage ist dann nur noch: Wer soll das System betreiben, und wie soll er das tun? Soll er direkt im Code rumfuhrwerken müssen oder bekommt er ein für ihn leichter zu handhabendes System. Woraus sich bei letzterem ergibt: neues Feature => mehr Komplexität. Du musst also immer abwägen, ob du Komfort oder weniger Komplexität haben möchtest.
Wenn man es so herum macht, dann muss ich ja für jeden "Ausgabezweck" irgendwo definieren
a) welche(s) Template(s) benötigt wird und
b) zusätzlich noch definieren, welche Action-Controller dafür von Nöten sind, um alle erforderlichen Daten aus dem Model dafür bereitzustellen
richtig?
Spontan fallen mir zwei wesentliche Arten von Action-Controllern ein: Der eine Typ soll eine allgemeine Art von Aufgaben erledigen, die mehrfach vorkommt, sich aber nur in Kleinigkeiten unterscheidet. Den kann man mit übergebenen Parametern steuern. Der andere Typ ist konzipiert für Spezialfälle. Dieses Controller sind so individuell, dass se nur für einen einzigen Fall zu gebrauchen sind und deshalb nicht flexibel mit Parametern versorgt werden müssen. Zwischen beiden Arten kann es beliebig viele Zwischenstufen geben.
Und das jedes Mal ggf. beides pflegen, wenn sich das Template als solches, oder im Template etwas ändert?
Irgendwo musst du die Änderung vornehmen. Die Frage ist dabei wieder: wer, wie und wo?
Was hieltest du denn von der Variante, diese Informationen jeweils in jedem Template mit zu speichern?
Prinzipiell Abstand. Das Template soll nur ausgeben und keine grundlegenden Entscheidungen treffen. Die Entscheidung, was auszugeben ist, ist abhängig vom Request. Bei einer Zeitung wird der Inhalt vom Chefredakteur bestimmt und nicht vom Layouter.
Ich dachte mir das Ganze eher in vielen kleinen Einzel-Templates (mit jeweils zugehörigem Action-Controller zur Beschaffung der benötigten Daten), die sich dann im Baukasten-Prinzip zusammenstellen lassen.
Im Grundgerüst der Seite müssen Platzhalter für die Module vorgesehen sein. Wenn das Grundgerüst-Template keine Daten für einen Platzhalter bekommt, dann fliegt letzterer eben einfach so raus und in der Ausgabe erscheint an der Stelle nichts.
Also bspw. ein Template mit Controller für die Breadcrumb-Navigation, eines für das Menü, eines für Kommentare zu einem Artikel, etc. Diese Einzel-Templates lassen sich dann nach Belieben in das Gesamt-Seiten Template integrieren (und zwar ohne irgendwelchen zusätzlichen Administrationsaufwand, bzw. Änderungen in irgendwelchen Konfigurationseinstellungen/ -dateien).
Der Aufwand bei einer Änderung ist immer da, ob du nun eine Konfigurationsdatei oder das Template änderst. Wie wird aber letzlich bei einem Request die Ausgabe der Einzel-Templates in das Grundgerüst eingefügt? Willst du das Grund-Template nach den Modul-Informationen scannen, die Module abarbeiten und deren Ausgabe einfügen oder willst du das Grund-Template ausführen und die Einzel-Templates sind als Funktionsaufruf (oder ähnlich) integriert?
Wäre das (deiner Meinung nach) eine praktikable Lösung (auch wenn sie vielleicht nicht 100%ig dem MVC-Modell entspricht)?
Der Entwicklungsschwerpunkt soll ja eindeutig auf größtmöglicher Flexibilität bei gleichzeitig möglichst niedrigem Pflege- und Administrationsaufwand liegen.
Das MVC ist ja kein Gesetz und man muss diesem Prinzip auch nicht bis ins kleinste Detail folgen. Es ist eine Orientierungshilfe, die man annehmen kann oder nicht. Das MVC-Muster hat sich bewährt, so dass ich ihm zu folgen versuche, das aber immer mit einer Beurteilung als Praktiker und nicht als Evangelist. Wie auch immer, es lohnt sich auf alle Fälle ein Blick über den Tellerrand. Wie haben es die anderen gelöst, was gefällt mir daran und was nicht?
Beispielsweise DotNetNuke. Ein Modul wird dort über die Administrationsoberfläche hinzugefügt. Man wählt das Modul aus und gibt an, in welche Pane - also in welchem Bereich des Grundgerüst - es hinzugefügt werden soll. Jenes Video zeigt ab kurz vor Minute 4:00, wie das dort gemacht wird. Dabei wird nicht das Template direkt geändert sondern die Konfigurationsdaten. Bei einem Request wird also nicht das Grundgerüst-Template nach Inhaltsmodulen durchsucht, sondern in der Konfiguration wird nachgesehen, welche Module verwendet werden sollen und an welcher Stelle sie im Grundgerüst einzufügen sind. Ohne Adminoberfläche kann man die Daten, welches Modul wo ausgegeben werden soll, in einer Konfigurationsdatei anlegen. Das Grundgerüst selbst wird sich selten ändern. Die Module und ihre Positionierung lassen sich jedoch auch so schon an einer zentralen Stelle konfigurieren und man braucht dazu noch nicht mal HTML-Kenntnisse, um über das Template gehend die Seite (in gewissen Grenzen natürlich) umgestalten zu können.
Lo!
Struppi