Klaus: OOP Konflikt

Beitrag lesen

Hallo.

Was hälst du von der Umsetzung von ihm?
Das versteh ich gut wie er es gemacht hat.

Alternativ wäre ich dafür die Verarbeitungsverzweigung in hidden-inputs zu stecken also:

<input type="hidden" name="class" value="klassenname"/>
<input type="hidden" name="action/method" value="action/methodenname"/>

Aber das klingt unsicher. Oder man machts etwas "versteckter" - in Sessions.
Beim laden des Formulars werden entsprechende Sessions gesetzt..

Mit der URL - ist immer son Ding, das es einmal gut aussieht und zweitens von der Technik passt.

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.

Ja stimmt es soll schon etwas abstrakter / allgemeiner werden so das ich soviel Code wiederverwenden kann, wie nur möglich.

»» 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.

Ich weiß aber nicht genau wie ich das umsetzen soll. Wie er?

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.

Okay dann lege ich dafür eine Methode an und rufe diese zu Beginn des Skripts auf. Soll das initialisieren der Settings im FronController passieren? Und ist es okay für jede Klasse eine eigene ini zu erstellen und in den KlassenControllern im Konstruktor parsen/einlesen zu lassen?

»» 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?

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?

Stimmt, hättest du Verbesserungsvorschläge?
Also sollte ich jedem Controller direkt sagen was er für welche Action braucht? Bzw. nee. Ich lege in jedem Model direkt fest was gebraucht wird und der Controller weiß nur - dieses Model oder diese Modelaction gehört zu dem und dem View..

Und wer baut am Ende die Seite zusammen?
Also die Views werden doch am Ende dem Controlelr übergeben und dann mache ich da eine Methode welche Header usw ausgibt nacheinander?
Also die Views sortiert ausgitb z.B.:
echo $this->Header;
echo $this->Navigation1;
echo $this->Body;
echo $this->Footer;

so in etwa?

Liebe Grüße,

Klaus