litterauspirna

Anhand meines Praktikums eine eher eigene Implementierung. Meine Chefin hat sich viel Mühe gegeben mir da was beizubiegen und das versuche ich nun umzusetzen. Wenn es soweit ist dann poste ich dir bzw. hier im Forum auf alle Fälle mal den Code. Momentan ist nur ein Beispiel anhand eines simplen Gästebuches, halt zur Übung um überhaupt erst mal ein Gefühl zu bekommen.

Momentan habe ich das so, ich habe einen frontController der so mit meinem MVC nichts weiter eigentlich zu tun hat. Über meine URL (hast du ja gesagt ist nicht so gut) lade ich zum Beispiel anhand eines Modul (?modul=) ein Model, View, Controller für die Darstellung des Index. Wenn ich nun z.B. einen Link klicke um zum Eintragsformular zu gelangen für einen neuen Eintrag lade ich anhand des action (?modul=gb&action=newEntry) meine Klassen NewEntryDatabaseModel, NewEntryController, NewEntryView. So war mein Grundgedanke dafür. Das heißt mein FrontController weiß von meiner MVC Implementierung nichts sondern lädt Klassen bzw. MVC Komponenten anhand der URL Adressierung. Daher denke ich bin ich schon ein wenig flexibel.

Was mich interessieren würde wie man, wenn man über URL Adressierung seine Klassen lädt das so übersetzen kann das es nun allgemein flexibel einsetzen kann. Denn soweit wie ich das gelernt oder besser gesagt verstanden habe sind Models, Controllers und Views ja doch immer Anwendungsspeziel. Ode rliege ich da falsch?

Gruß Litter

__________________
Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
http://www.lit-web.de

Mister Ad

dr.e.

Hallo litter,

MVC-Elemente sind Anwendungs-spezifisch - korrekt. Deshalb sollte man versuchen, die Problem-Domäne zu abstrahieren. Einmal hast du das mit dem Front-Controller ja schon getan, andererseits sollte (auch aus meiner Erfahrung bestätigt) MVC an sich abstrahiert werden, denn in dieserm Bereich gibt es auch immer wieder gleichartige Aufgaben und Verhaltensweisen über Anwendungen hinweg. Ein Punkt ist das Thema Routing/URL-Mapping in einem statischen MVC-Modell so wie du es beschreibst. Das lässt sich recht einfach in eine eigene Action packen, die für jede Anwendung wieder eingesetzt werden kann - durch Konfiguration "personalisiert". Beim APF übernimmt diesen Job der Page-Controller, der sich um das Gerüst der Seite, dessen Views und Controller kümmert.

Treibst du das weiter, schickt es sich dafür eine Komponente einzusetzen, die sowohl das Management von MVC- oder gleich HMVC - übernimmt als sich auch in ein Konstrukt einpasst, das hinsichtlich der URL-Abstraktion unterstützt. Gerade das URL-Mapping bzw. -Layout ist ein Thema, was meiner Ansicht nach durch viele MVC-Umsetzungen (1:1-Mapping auf Controller) sehr strapaziert wird. Hier fordere ich eine Abstraktion über Input- und Output-Filter. Somit ist es nicht notwendig, einen Controller in der URL zu definieren, sondern dieser kann ganz einfach durch das Gesamtkonstrukt implizit oder durch die codierte URL mehr oder weniger explizit definiert werden. Damit schränkst du dich auch nicht in der Länge der URL ein, wenn du in einer komplexen Applikation mehrere Controller brauchst oder must Krücken wie View-Helper zu Hilfe nehmen, die nichts weiter tun als die Wiederverwendbarkeit kaputt zu machen. Such mal im Software-Design-Forum nach Beiträgen zum Thema URL-Layout, wir haben das Thema schon sehr ausführlich diskutiert.

Ein konkretes Beispiel für ein Mapping kommt wieder auf den Anwendungsfall an, kann aber grundsätzlich sehr einfach sein, denn das APF basiert beispielsweise auf dem Paradigma, dass nur die effektiv notwendigen Parameter in der URL enthalten sein müssen. Es ist nicht notwendig, alle Controller/Views in der URL zu codieren, die in einem HMVC-Baum notwendig sind. Nehmen wir an, du hast eine Seite mit einem Header, einem Menü und einem Content-Bereich und auch das Haupt-Template (in vielen MVC-Implementierungen auch "Layout" genannt). Das erfordert nach MVC 4 Views und Controller - vielleicht 1-2 Models. Musst du das in der URL abbilden, braucht es 4 Parameter, zur Ansteuerung der Impressum-Seite ist effektiv aber nur 1 Parameter notwendig. Genau diesen solltest du auch in der URL haben und das ist auch kein Problem, da die 3 anderen entweder durch die Struktur des Baumes oder der expliziten Auszeichnung in der URL definiert sind. Hierbei muss jedoch nicht der Controller in der URL definiert sein, sondern Parameter, die auf die Steuerung des Baumes Einfluss haben (z.B. Seite 2 anzeigen, ...).

Wenn dich das Konzept näher interessiert - es bietet meiner Meinung nach wirklich die größte Flexibilität -, können wir uns gerne in einem anderen Thread drüber unterhalten. Ich würde den Thread hier ungern hijacken.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~