nicht angemeldet
echo $begrüßung;
Bei mir sieht MVC gerade so aus:
http://img3.imagebanana.com/view/1hwclav7/xx.jpg
So sieht das ja gar nicht schlecht aus. Nur das was du da an Code erstellt hast, erscheint mir nicht besonders klar nach Aufgaben getrennt und mit allgemeiner Wiederverwendbarkeit im Hinterkopf implementiert. Und manche Code-Teile tun effektiv nichts. Vielleicht hättest du doch schon jetzt deinen Code kommentieren sollen. Vielleicht haben sie ja für später eine Bedeutung.
Auch fängst du an, ein allgemeines Framework zu entwickeln, hast aber dabei immer im Hinterkopf deine konkrete Anwendung. Wenn das Framework gut werden soll, muss es jeder Anwendung eine Basis bieten. Du musst es also sehr abstrakt entwickeln. Die Anforderungen, die du an das Framework stellst, müssen dabei konkret aber anlassunabhängig formuliert werden. Das erfordert eine Menge Erfahrung. Die kannst du sammeln, indem du mit existierenden Frameworks arbeitest, ein Gefühl für ihre Arbeitsweise bekommst und dabei erkennst, welche Vorteile und welche Schwächen sie haben.
Desweiteren sieht die Ordnerstruktur anhand des Beispiels Newsletterklasse so aus:
Die Ordnerstruktur ist in Ordnung. Dein Problem ist das Innenleben deiner Klassen.
Das wäre natürlich statt
index.php?show=Views_Newsletter_NewReceiver
View/Newsletter/Registrierung
Wozu dient das Wort View? Webseiten zeigen immer was an. Du brauchst das "View" nur, um daraus einen Klassennamen zu bilden. Wenn die Default-Routing-Regel nicht ausreicht, einen passenden ActionController-Namen zu ermiteln, kannst du eine spezielle definieren, die den Namen passend zusammenstellt. Beim ZF zerlegt der Router die URL in Parameter. Aus bestimmten Parametern bildet der Dispatcher den ActionController-Klassenamen. Der Router kann für fehlende Teile auch selbst Parameter hinzufügen.
Aber das wäre jetzt rumfuchtelei mit mode_rewrite.
Nö, da kommt eine ganz allgemeine Regel rein, die den Request nur auf index.php lenkt ohne irgendwelche URL-Teile zu GET-Parametern umzuschreiben. Zur Auswertung des Requests gibt es den Router. Der nimmt REQUEST_URI und wendet darauf seine Regeln an.
Ausserdem muss ich die Klassen dann eindeutschen, weil die Seite ja eine deutsche Zielgruppe hätte.
Auch hier kann der Router für eine Übersetzung sorgen.
Wenn ich das jetzt so umsetzen wollen würde sollte ich dann 3 GET Parameter daraus machen (show1,show2,show3) und diese aneinanderreihen oder sollte ich daraus einen Parameter machen? Also wie würdest du das angehen?
Siehe oben, REQUEST_URI direkt auswerten.
» Ich sehe nicht, wofür du die Variable $set_settings anlegst. Auch erschließt sich mir nicht, warum du ein Objekt von settings anlegst. Im weiteren Verlauf greifst du nur statisch auf die Klasse zu.
Um die Klasse zu instanzieren da sie im Konstruktor alles wichtige an Settings lädt. Z.b. - bin ich im Internet oder im Develop-Mode(zeigt alles Fehler an E_ALL | E_STRICT), die Zeitzone die ich verwende, Name des Projektes, der URL, Name des smtp-Server für mail() usw..
Okay - die Variablenzuweisung ist Schwachsinn.
Also wieder ein Fall von Konstruktormissbrauch. Wenn du sowieso die Konfigurationswerte statisch abfragbar ablegst, kannst du auch gleich eine statische Methode zu deren Ermittelung erstellen.
Hm, wie sonst soll ich dafür sorgen das er [der FrontController] mit den Requests arbeitet, sie abfängt usw? Soll ich dafür extra eine Methode schreiben und sie dann in der index.php aufrufen?
Wie gesagt, der Konstruktor ist für eine grundlegende Initialisierung der Instanz da. Weiterführende Initialisierungen kann man in eigenen Methoden unterbringen. Die über Initialisierung hinausgehende Arbeit kommt auf alle Fälle in (eine) eigene Methode(n). Beim FrontController vom ZF heißt sie dispatch(). Und wenn man auf großartige Initialisierungen verzichten kann, gibt es die statische Methode run(), die sich selbst eine Instanz erstellt und davon dispatch() aufruft.
» »» public $informations=array();
» (Das englische Wort information hat keine Pluralform.)
Ich weiß - allerdings klang das für mich einleuchtener, das es um "mehrere" geht.
Naja, für den Engländer ist es einleuchtender, dass "information" sowas wie "Sand" ist: besteht impliziert aus mehreren Einzelteilen.
Desweiteren habe ich mir - auch wenns im Geschichte LK war, etwas für die Views einfallen lassen:
Wie ist die Idee?
Vielleicht zu aufwendig. Der Controller sollte eigentlich seine Schäfchen kennen, ohne sie vorher befragen zu müssen. Was kann er denn tun, wenn das Template mehr Platzhalter meldet als Werte aus der Datenbank abzufragen gehen? Genausowenig wie das Template was machen kann, wenn der Controller einen Wert zu wenig liefert. Wenn du allerdings die View mit spezifischen Informationen spickst, die das Model eigentlich zu verbergen hat, bringst du dir direkte Abhängigkeiten zwischen beide. Genau die versucht man ja zu vermeiden.
Und was ist, wenn der Wert aus dem Model vom Controller erst noch bearbeitet werden muss, bevor er an die View gehen kann? Wie willst du sowas implementieren?
Ich möchte das alles auf jeden Fall verstehen - auch bevor ich ein Framework einsetze. Vllt werde ich das ZF später nutzen, sobald ich das ganze verstanden habe, mir reichts zu wissen "das könnte ich auch umsetzen" - von der Theorie.
Ich ging bisher andersrum an die Sache ran. Zunächst versuche ich was Vorgefertigtes zu nehmen, stelle dann aber fest, dass es meinen Anforderungen nicht entspricht oder vielleicht zu umständlich und aufgebläht ist. Dann setz ich mich hin und erstelle was eigenes, nehme die guten Ideen mit und versuche das in meinen Augen weniger gelungene auf passendere Weise zu implementieren.
echo "$verabschiedung $name";