OOP Konflikt

[Klaus]

Hi.

Ich sehe, du versuchst immer noch nicht nur inhaltlich sondern auch strukturell deinen eigenen Weg zu gehen. Du nimmst zwar ein paar Idden auf, setzt die aber nicht wie angedacht ein. Versuch doch mal, deine jetzige Struktur um eine andere Aufgabe zu erweitern. Geht das gut? Dann kann dein Weg nicht so schlecht gewesen sein. Geht es nicht oder nur mit Anpassungen, ...

Ach verdammt.Eigendlich verstehe ich sollche Dinge wahnsinnig schnell aber irgendwo war wohl der Zeitpunkt wo ich ins Labyrinth gerannt bin... Jetzt finde ich das Ende nicht.

Bei mir sieht MVC gerade so aus:

http://img3.imagebanana.com/view/1hwclav7/xx.jpg

Desweiteren sieht die Ordnerstruktur anhand des Beispiels Newsletterklasse so aus:

/index.php
/FrontController.php
/Config/Settings.php
/Config/inis/settings.ini
/Config/inis/newsletter.ini // jede klasse bekommen - falls nötig, ihre eigene INI
/Dispatcher/dispatcher.php
/Helper/ // Hilfsklassen, wie statische Datenbank-Klase
/Helper/ErrorHandling/
/Scripts/ // Javascripte
/Styles/ // CSS-Dateien
/Views/Newsletter/ // die views
/Models/ // die Models
/Controller/ // die Controllers

Eine URL hat Außenwirkung. Gestalte ihr Aussehen nicht nur nach technischen Erwägungen sondern eher so, wie du als Benutzer sie sehen wollen würdest.

Das wäre natürlich statt
index.php?show=Views_Newsletter_NewReceiver

View/Newsletter/Registrierung

Aber das wäre jetzt rumfuchtelei mit mode_rewrite. Ausserdem muss ich die Klassen dann eindeutschen, weil die Seite ja eine deutsche Zielgruppe hätte.
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?

»» include('Config/settings.php'); $set_settings=new settings();

(Ein include ist keine Funktion und braucht keine Klammern.) 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.

»» include('FrontController.php'); $FrontController=new FrontController();

Auch der FrontController wird nach seiner Instantiierung nicht mehr gebraucht. Er hat ja noch nicht mal öffentliche Eigenschaften, die man verwenden kann. Du brauchst also auch dafür eine Instanz in einer Variable ablegen. Was allerdings schwerer wiegt ist, dass du den Konstruktoraufruf missbrauchst. Du initialisierst nicht nur sondern lässt ihn die gesamte Arbeit machen. Nach außen hin sieht das ganze wie ein Funktionsaufruf aus. Es bietet sich dann eher an, eine statische Methode zu verwenden. Wenn du für interne Zwecke eine Instanz benötigst, kannst du sie in einer privaten (statischen) Klassenvariable ablegen.

Hm, wie sonst soll ich dafür sorgen das er mit den Requests arbeitet, sie abfängt usw? Soll ich dafür extra eine Methode schreiben und sie dann in der index.php aufrufen?

»» public $informations=array();

(Das englische Wort information hat keine Pluralform.)

Ich weiß - allerdings klang das für mich einleuchtener, das es um "mehrere" geht.

Bezeichner sollten sprechend sein, so dass man ihre konkrete Aufgabe zumindest erahnen kann.

Okay ich sollte also mehr darauf achten das man erkennt was woher kommt..

Desweiteren habe ich mir - auch wenns im Geschichte LK war, etwas für die Views einfallen lassen:

Eine Views.php von der jeder erbt. Sie hat folgende Methoden:

public function tellNeedles(){
  // Hole Ausdrücke von parseText()
  // Hole ggf. sonstige Informationen
  return array
}

parseText($text){
 // Parse den Text
 // Schreibe alles Ausdrücke raus und packe sie in ein Array
 return array
}

public function getNeedles($text,$result){
 // Ersetze Ausdrücke durch Ergebnisse von Model.
 // Gebe den View zurück
 return $View;
}

Die Views die von ihr erben haben eine Art Template-System.
Überall, wo etwas hinsoll aus einer Datenbank z.B. steht {|Tabellenname.Ausdruck|}
Z.B.
$output="<html><head><title>{|Projectdatas.title|}</title></head><body></body></html>";

Der Controller kann also per tellNeedles sich zeigen lassen was er braucht und per getNeedles bekommt die/der View was er/sie braucht.

Die View.php wird per extends eingebunden und vllt kann man ja dazu ein Interface oder eine Abstrakte Klasse schreiben, die dies zur Vorraussetzung macht.

Wie ist die Idee?

Ich müsste meinen Kopf mal aufräumen da ich nicht durchblicke wie die Requests(GET / POSTS) am besten verarbeitet werden, hast ja beim letzten Post gesehen was dabei rauskommt. Naja ich habe dir ja oben ein Bild gemacht wie ich das zur Zeit sehe. Wenn das nicht stimmt. Wissen wir ja schonmal das ich bisher schonmal ganz falsch an die Sache rangegangen bin.

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.

Liebe Grüße, danke für deine Mühe.