Zergling-new

Hallo,

bei einem URL-Request stehen meinem MVC unter anderem folgende Einstellungen zur Verfügung:
handle (ansicht, download, ..)
charset (utf-8, iso-8859-1, ..)
language (deDE, enUS, ..)
format (html, xml, ..)

Welche ordne ich nun dem Controller, welche dem Model und welche dem View zu?

Ich würde sagen der Controller sendet den header(), bekommt daher $handle (content-disposition) und $charset (content-type;charset) übergeben (logischerweise auch den Rest, aber den darf er nur weitergeben).

Model bekommt nur $language, da intern alles UTF-8 abgelegt ist.

View bekommt $charset (zwecks Kennzeichnung des Zeichensatzes über den body, html-meta, xml-encoding, css-charset, ..), $language (html-meta, xml-lang, ..) und klar: $format.

Stimmt ihr mir da zu?
Wer ist für die interne Zeichensatz-Konvertierung zuständig, der Controller, das Model selbst?

Würdet ihr gzip-Kompression implizit verwenden? Wäre zumindest konsequent es auch als optionalen Parameter hinzuzufügen. Als $handle view-compressed eventuell.

Außerdem habe ich das Problem, dass der Controller anmelden sollte, welche Sprachen und Formate er unterstützt, ist allerdings schwierig, wenn sprache und format in der URL vor dem Controller und der Action angegeben werden müssen (und diese auch noch optional sind). Ich habe die Reihenfolge gewählt, weil der Sende-Typ (handle) absteigend zum Zeichensatz, Sprache, Format, .. die elementarsten Eigenschaften des Angebotes sind. Zumindest strukturell. Oder seht ihr das umgekehrt, dass die Sprache bzw. Format, Zeichensatz und Sendetyp mehr eine Untermenge der Seite sein sollten, also eher Parameter für die Seite sein sollten?

Mister Ad

dr.e.

Hallo Zergling,

da ich leider kein UML zu deiner Idee habe, fällt es mir etwas schwer, das genau fest zu legen. Hintergrund: Model muss in Verbindung mit der 3-Schicht-Architektur kein Bestandteil der Präsentations-Schicht sein. Model kann in diesem Fall auch eine Business-Komponente (kein Daten-Objekt) sein, das das Verhalten und die Konfiguration der Applikation vorhält.


Header und Charset würden in diesem Fall gemeinsame Applikations-Informationen sein, denn eine Webseite kann beispielsweise immer nur unter einem Zeichensatz ausgeliefert werden. Daher stecke ich das in die Business- oder Datenschicht (charset), weil ich meiner Präsentations-Schicht nich zumuten möchte sich mit diesen Themen rumzuschlagen.


Wenn Model hier gleich Business-Schicht, stimme ich zu, mit Zeichensatz sollte sich die Präsentation nicht beschäftigen müssen.


Diese Informationen sollte der View sich aus dem Model ziehen, oder besser: der Controller sollte diese Informationen aus dem Model ziehen und an den View übergeben.


Ich verwende es bisher nicht, hab auch keine Performance-Erfahrungen damit.


Das verstehe ich nicht. Egal, wie du dein URL-Layout wählst, du solltest immer auf alle Attribute zu jeder Zeit der Abarbeitung deiner Applikation haben. Baust du dir hier ein Abhängigkeit ist das ein Problem.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Zergling-new

Danke für die Einschätzung, ich schau mir des Bayernspiel jetz an und schreib heut Abend nochmal was dazu.

Zergling-new

Und wer sendet header() am Ende tatsächlich, Controller oder Model? Ist der Controller wirklich einzig dazu da, View und Model zu verbinden? Also der Anfrage folgend dem passenden View das passende Model zu übergeben?

dr.e.

Hallo Zergling,

ich werde das mal Stück für Stück beantworten:

Das Model an sich ist eigentlich nur - wie der Name schon sagt - eine "Beschreibung" der Anwendung. "Beschreibung" im Sinn von

- Aussehen
- Verhalten
- Daten

Der Controller besitzt damit die Aufgabe die Ausgabe, bzw. Steuerung des Programms an Hand des Models zu übernehmen. Und Controller wiederum gibt es in mehreren Schichten, wobei die Schichten die jeweiligen Aufgabenbereiche definieren. Will heißen, dass ein Controller der Präsentationsschicht sich mit den Aufgaben der Präsentation der Applikation zum Client hin beschäftigt und deswegen auch für die Steuerung der Ausgabe (Header) zuständig ist. Auch die Business-Schicht kennt interne Redirects, beispielsweise bei einem Eintrag in ein Gästebuch, wonach der Benutzer auf den Anzeige-View weitergeleitet wird. Damit wird auch die Business-Schicht einen Header werfen.


An sich nicht falsch, nur mit dem Zusatz, dass der GUI-Controller im Fall des FrontControllers auch oft nach den Regeln und Gegebenheiten des Models handelt, sprich sich Informationen über die anzuzeigenden Felder des (Daten-)Models holt. Man sollte ob dieser Gleichbenamung von (Daten-)Model und (Status-)Model grundsätzlich besser von Domain-Objekten (=Daten-Model) und dem Model der Anwendung hinsichtlich Verhalten (=Workflows) und Darstellung sprechen, dann wird das klarer. In unterschiedlichen Frameworks gibt man dem Domain-Objekt einiges an Logik mit, so dass dieses sich selbst speichern kann (CRUD). Das wiederum ist zwar nett, aber führt dazu, dass früher oder später zu viel Logik in ein Domain-Objekt gelegt wird und das nicht mehr handhabbar ist.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Zergling-new

Das klingt also danach, dass das Pattern relativ anpassbar ist, abhängig von der Komplexität seiner Umgebung?!
Letztlich aber der Controller für die Ausgabe zuständig ist, gefüttert mit den Daten des Models?!
Habe ich dich da dann richtig verstanden?

dr.e.

Hallo Zergling,

Was ich beschreibe sollte nicht nach beliebiger Flexibilität klingen, da ein Pattern üblicherweise _einen_ definierten Problemfall benennt und eine Lösung skizziert. Den Fall den ich skizziert habe ist der, dass es in mehreren Schichten der Anwendung mehrere Typen von Controllern gibt, denen unterschiedliche Aufgaben zubemessen werden.


Ein Page- bzw. Front-Controller, oder - wie ich diese in meinem GUI-Modell habe - Document-Controller ist per se für die Generierung von Ausgaben oder die Koordination (FrontController) von Business-Komponenten zuständig. Letztere beeinflussen natürlich auch indirekt die Ausgabe in dem Sie dem Model entsprechende Werte implantieren, die wiederum von einem Document-Controller zur Steuerung der Ausgabe verwendet werden können.

Ist das für dich nun klar? Falls nein, kann ich dir gerne ein Beispiel zeigen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Zergling-new

Zugegeben nicht komplett.

dr.e.

OK. Was war denn genau nicht klar? ich tippe mal darauf, dass es mehrere Controller-Typen geben kann, richtig?

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Zergling-new

Weißt du ich hab das ganze schon in kleinen Projekten am Laufen, aber so richtig ne Linie drin hab ich noch nicht.

Sagen wir ich habe eine Bootstrap-Anwendung, der Request ("gallery/view/meine-urlaubsfotos.html") wird an den FrontController übergeben, per Konstruktor. Der zerlegt das ganze in modul=gallery, aktion=view, id=meine-urlaubsfotos, format=html.

Benötigen wir neben dem FrontController noch einen Controller, einen Gallery-Controller? Eigentlich ist das Schema ja immer gleich, würde also sagen wir verzichten drauf.

Der FrontController erstellt nun ein Model anhand modul/aktion. Woher bekommt er das Model? Ist es eine eigene Klasse (GalleryViewModel) oder eine Aktion einer GalleryModel-Klasse?

Gleiches beim View?
Was macht mein View eigentlich, außer eine Template-Datei laden und mit dem Model füttern? Dann brauch ich eigentlich nur eine einzige View-Klasse pro Format (das eben weiß, wie das Model in das HTML-Template eingefügt wird).

Dann hätte ich also einen FrontController, pro Format (HTML, XML, ..) ein View, pro Aktion ein Template-File, auf das mein View zugreift und pro Aktion natürlich ein Model.

So ganz weiß ich auch noch nicht, wie ich hier meine Language-Einstellung und das mit dem header() unterbringe. Ist die Sprache eine fundamentale Einstellung oder nur ein normaler Parameter wie "meine-urlaubsfotos"?


Das mit den Controllern, ich denke ich werde nur einen Front- (oder wie du es nennst Document-)Controller einsetzen. Um das zu verstehen muss ich MVC erstmal im Blut haben. Das Prinzip habe ich zwar verstanden, aber die konkrete wiederverwendbare Umsetzung finde ich nicht so einfach.