scoops

Hallo Kollegen,

ich stecke in der Planung (m)einer Webanwendung. Bisher habe ich nur "übersichtliche" PHP-Skripte oder Module erstellt, deshalb fehlt mir der Blick aufs Ganze. Aber ich bin sicher ihr könnt mir helfen

Beispiel: Ich habe eine Webseite, die Code-Snippets verwaltet. Auf diese soll auch von anderen Webseiten aus zugegriffen werden. Zusätzlich dazu die üblichen Elemente wie Newsletter, Kontaktformular etc.

Ich habe begonnen die Dateien nach (Fake-)MVC aufzuteilen, wobei mein Controller die Business-Logik enthält und das Model nur mit der Datenbank kommuniziert.
Jede View repräsentiert eine Seite auf meiner Webseite, also z.B. home.php, scripts.php, top10_scripts.php, contact.php.
Entsprechend gibt es jeweils einen Controller.
Models gibts class Script {} und class Newsletter {}.

Bis hierhin vernünftig, oder?


Jetzt möchte ich aber auf jeder Seite ein Newsletter Modul haben, ohne in jedem Seitencontroller und in jedem View praktisch den gleichen Code zu haben.
Nur wie lagere ich den Code aus? Macht es Sinn, jedes Modul in einem eigenen Ordner wieder nach MVC aufzuteilen...
Und wie binde ich das Modul dann ein, mit include im View?

Bin dankbar für jede Idee und jeden Link
Beste Grüsse,
Scoops

Mister Ad

tarzanhb

Moin,
wäre es nun nicht angebracht, sich über sein Framework gedanken zu machen?
Sprich Funktionen, die du immer wieder brauchst, wie dein Newsletter packst du in deine Framework als Klassen.
Bei bedarf kannst dann einfach per Aufruf deinen Newsletter einbinden.
Dazu einfach z.b. mal schauen wie das ZendFramework aufgebaut ist, oder andere PHP Frameworks.
Dann solltest du auch bestimmt eine Inspiration für deinen Weg finden.

Paul.Schramenko

Und mal ehrlich dieses Thema wurde schon zig mal, und das nicht nur in diesem Forum, besprochen. Benutz doch einfach die SuFu. Da findest du ganz ganz viele Beispiele und Diskussionen um den Aufbau, den Sinn und alles andere was es zu MVC zu sagen gibt!

__________________
"My software never has bugs, it just develops random features."
"Real programmers don't comment. If it was hard to write, it should be hard to understand!"
Positive Bewertungen sind nicht unwillkommen...

nikosch

Mit einem Framework hat das nicht viel zu tun. Das wird ja wohl kaum schon die Geschäftsobjekte bieten.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

tarzanhb

Nein definitiv nicht. Aber man sieht dort, wie Funktionen eingebunden werden können, anstatt Sie wie hier gedacht per include einzubinden.
Entweder man übernimmt dann dieses Konzept und erweitert es um seine Bedürfnisse (also den Newsletterteil), oder man schreibt auf dieser Basis seine eigene Integration von Funktionen.
Es geht ja darum, sein Konzept Sinnvoll weiter umzusetzen, wenn man sich schon Gedanken macht in diesem Bereich.
Da es schon fertige Konzepte gibt, sollte man sich die doch anschauen.

dr.e.

Hier ein paar Stellen, die den Thread IMHO erledigen:

• http://www.php.de/software-design/68...u-cms-mvc.html (Frage zu CMS/MVC)
• http://www.php.de/software-design/64...unktionen.html (Parameter für Controller-Funktionen)
• http://www.php.de/software-design/62...-struktur.html (Integration eines Pluginsystems in einer HMVC Struktur)
• http://www.php.de/software-design/60...ac-ansatz.html (URL-Design für PAC-Ansatz)
• Plugin System - Forum: phpforum.de
• http://www.php.de/software-design/56...lling-mvc.html (erweitertes Controlling (MVC))

Und hier noch ein Link: http://www.php.de/php-einsteiger/689...c-pattern.html

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

scoops

Hab mir jetzt alles auffindbare durchgelesen, wobei ich zugeben muss, manchen Ausführungen konnte ich noch nicht folgen.

Auch noch nicht ganz klar ist mir, wie die Actions von Modulen in HMVC-Einheiten (über die URL?) gesteuert werden:
Bisher schauen meine URLs so aus: www.example.org/controller/action. Diese URL könnte also z.B. www.example.com/script/showAll lauten, womit das Template 'script.php' geladen und geparst wird, und alle vorhandenen Scripte angezeigt werden.
Auf genannter Seite binde ich nun über Template-Tags ein Newsletter-Modul ein. Ein Benutzer trägt sich ein und sendet das Form ab, es wird also Newsletter->register() aufgerufen.

Macht es Sinn, die URL nun wie folgt zu haben: www.example.com/script/newsletter/register? Bei 3 Angaben weiss mein Router, dass die Zweite das Modul sein muss. 'script' brauche ich ja nach wie vor, um das richtige Layout anzuzeigen.

dr.e.

Hallo Scoops,

du stößt an dieser Stellen genau auf das Problem derartiger URL-Layouts: es kann immer nur eine Hierarchie abgebildet werden und kein Baum von HMVC-Einheiten. Möchtest du einen solchen - sprich mehrere Templates pro Seite - haben, erfolgt die Steuerung über URL-Parameter und die Baum-Struktur selbst.

Ein Baum-Knoten ist dabei für die Darstellung des Registrierungs-Formulars zuständig, stellt dieses dar und verarbeitet die Eingaben. Dabei muss die Action und die Methode der Action überhaupt nicht in der URL stehen, sondern diese kann auch http://www.example.com/newsletter-registration heißen. Wichtig bei einem HMVC-Ansatz ist ebenso, dass du nur diejenige Teile in der URL abbildest, die auch für den Aufbau des Baumes notwendig sind. Was innerhalb des Baumes passiert ist zunächst nach aussen oft gleich (ein Menü, ein Header, ein Content-Bereich) und in einem der dreien ist das Modul eingebunden.

Schön zu sehen ist diese Art der Einbindung beispielsweise auf der Seite Kontakt :: Adventure PHP Framework (APF). Hier wird einfach das Kontakt-Modul auf der Seite "034-Kontakt" eingebunden ohne dass ich die komplette Baum-Logik und den Baum-Zustand in der URL transportieren muss. Intern kümmerst sich dann der entsprechende Controller des MVC-Knotens um die Verarbeitung des Moduls solange dieses im Baum hängt.

Ich hoffe, das hilft dir einen Schritt weiter.

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

scoops

Danke Doc
Die Module binden sich also nicht entsprechend der URL ein, sondern über das Template. Dabei ist es aus Sicht der URL einzig wichtig, dass ich die URL zum dem Controller route, der dann das entsprechende Template parst. Richtig? Dann sollte dieses Diagramm die gegenseitigen Aufrufe als Schritte korrekt darstellen: http://img257.imageshack.us/img257/1...chitecture.jpg

Dann wäre mir nur noch eine Sache unklar: wie bindet der HauptController nach dem Parsen des Templates den/die ModulController ein, sodass diese von sich aus auf Benutzereingaben reagieren können? Z.B. der KontaktController auf das Absenden des Formulare. Genau so wie der Front Controller den über die URL angeforderten Controller?

Könnte so nicht der HauptController versehentlich auf eine Benutzereingabe reagieren, die eigentlich für ein Modul gedacht waren? Oder wahrscheinlicher: bei zwei eingebundenen Pagination-Modulen würde eine Benutzereingabe ja beide Module beeinflussen.

dr.e.

Hallo Scoops,

Fast. Es kann natürlich Elemente (lösen wir uns mal vom Begriff Template und Modul) geben, die basierend auf den Informationen der URL eingebunden oder eben nicht eingebunden werden. Grundsätzlich ist es jedoch in einer HMVC-Umgebung nicht möglich und auch nicht notwendig, alle Elemente in der URL abzubilden. Statische Elemente sind auch durch statische Einbindung ausgezeichnet, im Inhalte-Bereich einer Seite - oder auch an beliebigen anderen Stellen - können dynamische Elemente dann an Hand der URL/Session/Cookies/... eingebunden sein.

Explizites Routing ist im HMVC-Fall nicht notwendig, da der Baum diese Aufgabe mehr oder weniger übernimmt. Der Baum wiederum wird durch einen Front- bzw. Page-Controller aufgebaut uns dieser übernimmt die Verantwortung, dass die korrekten Controller der eingebunden Module ausgeführt werden.

Das Diagramm spiegelt keine HMVC-Struktur wieder, weil du dich gedanklich immer noch nicht von der "ein Controller - ein Template"-Logik gelöst hast. Die Struktur ist in der von mir beschriebenen Art tatsächlich ein Baum aus lauter einzelnen Elementen die für sich genommen auf jeder Hierarchie-Ebene existieren könnten (sofern sie dort eingehangen würden).

Es gibt kein Haupt- und Unter-Controller-Struktur, sondern jeder Controller könnte der Haupt- und Unter-Controller in der Baum-Struktur sein. Um diese Struktur aufbauen zu können, braucht es eine Komponente, die genau diese Aufgabe versteht. Beim APF ist das der Page-Controller, der an Hand der Informationen des Root-Templates den Baum entsprechend aufbaut. Selbiges gilt für die Ausführung des geforderten / der geforderten Controller. Steuerst du das nicht zentral, wird die Umsetzung nicht gelingen, weil du die Abhängigkeiten nicht abstrahiert hast.
Beim Kontakt-Formular passiert im Grunde nichts spannendes, denn das Modul wird einfach - sofern per URL angefordert - immer in den Baum eingehangen und vom Page-Controller ausgeführt. Im Modul entscheidest du dann, was mit den Nutzer-Eingaben passieren soll. Das ist auch der große Vorteil, dass du dir um die umliegenden Elemente keine Gedanken (in Form von Code) machen brauchst.

Diese Aufgabenstellung ist keine HMVC-spezifische, sondern muss einfach durch Abgrenzung von Elementen gegeneinander erreicht werden. Das kann durch entsprechende Präfixe oder das Mitgeben von Namespaces passieren. Dies ist jedoch erst einmal zweitrangig gegenüber der obigen Aufgabenstellung.

Nebenbei gefragt: hast du das APF und dessen HMVC-Mechanismus schon mal genutzt?

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