REQUEST Handling

[Checklor]

Hallo.

mein Projekt hat viele Klassen.
Ich zähle mal ein paar auf:

Blog, Newsletter, Kontakt, PM-System, LOGIN/OUT, Registrierung

So. Alle diese Klasse werden am Anfang des Aufrufs der Seite index.php included und initialisiert.

In den Konstruktoren wird jeweils angefragt

if (isset($_POST['Das Formular der Klasse'])) {
   // RUFE DIE METHODE DER KLASSE AUF
} ELSE {
  // Tue garnichts.
}

D.h. also wenn ich die Seite zum ersten mal lade ohne das ein Request sien könnte, werden 6 Klassen umsonst includet, initialisiert und in deren Konstruktoren mind 3 IF-Abfragen bearbeitet. Sprich 18 IF-Abfragen umsonst.

Wie löst ihr sowas?
Diese Geschwindigkeitsbremse ist mir erst jetzt aufgefallen nachdem mein Projekt ein halbes Jahr steht -______-.

Mit freundlichem Gruß,

Bernd

[Tom]

Hello,

Wie löst ihr sowas?

Durch saubere Trennung der Aufgaben und bedingtes Include.

In deinem Falle wäre das: es gibt einen Rahmen, der alle Formulare kennt und weiß, welche Klasse dazugehört. Wenn Du die Submitbuttons entsprechend benennst

<input type = "submit" name="btn[formularname][aktionsname]" value="...">

dann kannst Du beim Post-Request bequem erkennen, welche Klasse dazugehört, um den Request zu verarbeiten und kannst auch bestimmen, ob der User überhaupt berechtigt ist, diesen Request abzusetzen.

Ich lese aber zwischen Deinen Zeilen, dass Du gar nicht soweit von einer solchen Struktur entfernt bist.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Checklor]

Hi.

<input type = "submit" name="btn[formularname][aktionsname]" value="...">

Also wie wäre denn folgendes:

Im Formular:

<input type = "submit" name="btn[Klassenname][formularname][aktionsname]" value="...">

Ist btn dann ein 3 demensionales Array? :-[
In der index.php folgendes:

if(isset($_POST)){
   include(btn[0]);
}

und in der Klasse wird dann per switch, case auf die Aktion passende Methode aufgerufen.

Lg,

Checklor

[Tom]

Hello,

Also wie wäre denn folgendes:

Im Formular:

<input type = "submit" name="btn[Klassenname][formularname][aktionsname]" value="...">

Ist btn dann ein 3 demensionales Array? :-[

Ja, sozusagen :-)

In der index.php folgendes:

if(isset($_POST['Klassenname'] and plausibel() ))

{

include( 'Klassenname.class.php');

$class = new('Klassenname');        ## Instanz könnte man eventuell auch als Rückgabewert
                                         ## des include() aufbauen.

}

und in der Klasse wird dann per switch, case auf die Aktion passende Methode aufgerufen.

genau!

Allerdings würde ich das bei OOP nicht per Switch machen, sondern durch entsprechende Zuweisung an eine Funktionsvariable.

Die Klasse wird ja nur benötigt, wenn eine ihrer Methoden vom User angefragt wurde.
Wenn sie angefragt wurde, wird die passende Klasse included.
Und wenn deren weitere Prüfung ergibt, dass die Aktion zum Formular passt und aufgrund der Vorgangsdaten in der Session jetzt auch sinnvoll ist, dann wird sie ausgelöst.

WEnn Du das nach außen nicht offen elegen willst, welcher Button zu welcher Klasse gehört, kannst Du natürlich auch eine Transformationstabelle zwischenschalten.

btn[23489067564] gehört dann eben zu Klasse 'xyz' und zu Formular 'doedelblah'.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

vielleicht auch so:

if(isset($_POST['Klassenname'] and plausibel() ))
  {
    include( 'Klassenname.class.php');

$class = new Klassenname($formularname,$aktionsname);

## Instanzvariable könnte man eventuell auch gleich
                           ## als Rückgabewert des include() aufbauen.

}

Wenn alle diese Klassen gleich aufgebaut sind, kann das auch im Konstruktor geregelt werden, den Formularnamen und den Aktionsnamen aus dem Post-Array auszulesen, denn das ist ja trotz OOP immer noch superglobal.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Checklor]

Hi.

Wenn alle diese Klassen gleich aufgebaut sind, kann das auch im Konstruktor geregelt werden, den Formularnamen und den Aktionsnamen aus dem Post-Array auszulesen, denn das ist ja trotz OOP immer noch superglobal.

So hatte ich das eigendlich auch vor.

[Tom]

Hello,

Hi.

Wenn alle diese Klassen gleich aufgebaut sind, kann das auch im Konstruktor geregelt werden, den Formularnamen und den Aktionsnamen aus dem Post-Array auszulesen, denn das ist ja trotz OOP immer noch superglobal.

So hatte ich das eigentdich auch vor.

[Anm: Standard mit 'd', eigentlich mit 't'] :-)

Die Formulare könnten dann ihrerseits wieder Klassen sein, die nachgeladen werden, da ja immer nur ein Formular auf einmal aktiv sein kann. Und steuern kannst Du das dann alles über den Erfolg des Includes.

Allerdings muss man hier aufpassen und darf keine Werte aus dem POST-Array, auch keine Bezeichnernamen, direkt in die Verarbeitung übernehmen. Externe Werte sind böse[tm].

Du müsstest dir also zuerst eine Formatprüfung bauen, die die Namen auf Zulässigkeit checkt. Das wird i.d.R. einfach die Feststellung sein, dass keine Pfade in den Namen oder Werten codiert sind.

Dann könnte man als nächstes schauen, ob ein entsprechendes File zum Includen vorhanden ist.
In der äußeren Hülle eben die Sammelklasse und intern dann die Formularklasse, die von der jeweiligen Sammelklasse erbt.

Nach dem Laden der Formularklasse fragst Du dann einfach, ob eine entsprechende Methode mit dem Namen $aktionsname vorhanden ist und ruftst die dann auf.

http://de.php.net/manual/de/function.method-exists.php

Du erhältst dadurch eine hierarchische Struktur und musst immer nur sehr wenige Klassen, die ben zum jeweiligen Pfad gehören, laden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Dann könnte man als nächstes schauen, ob ein entsprechendes File zum Includen vorhanden ist.
In der äußeren Hülle eben die Sammelklasse und intern dann die Formularklasse, die von der jeweiligen Sammelklasse erbt.

Nach dem Laden der Formularklasse fragst Du dann einfach, ob eine entsprechende Methode mit dem Namen $aktionsname vorhanden ist und ruftst die dann auf.

http://de.php.net/manual/de/function.method-exists.php

Du erhältst dadurch eine hierarchische Struktur und musst immer nur sehr wenige Klassen, die ben zum jeweiligen Pfad gehören, laden.

PHP bringt doch schon sehr mächtige Mittel mit, um sich gerade diese include-Orgien und Abfragen mehr oder weniger zu sparen: Autoloading. Wobei die Nutzung der Funktion __autoload() nur bei Projekten funktionieren dürfte, die exakt einen Autload-Mechanmismus haben und keine Erweiterbarkeit benötigen. Schlauer ist hingegen die Nutzung von spl_autload_register(), weil dort Mehrfachverwendung für unterschiedliche Zwecke möglich ist. Oder man vertraut das Autoloading direkt dem anbietenden Framework seiner Wahl an, beispielsweise Zend::Loader.

Autloading bringt die größten Performancegewinne dadurch, dass wirklich nur die Klassen geladen, geparst und verfügbar gemacht werden, die durch die Codeausführung wirklich benötigt werden.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

PHP bringt doch schon sehr mächtige Mittel mit, um sich gerade diese include-Orgien und Abfragen mehr oder weniger zu sparen: Autoloading. Wobei die Nutzung der Funktion __autoload() nur bei Projekten funktionieren dürfte, die exakt einen Autload-Mechanmismus haben und keine Erweiterbarkeit benötigen. Schlauer ist hingegen die Nutzung von spl_autload_register(), weil dort Mehrfachverwendung für unterschiedliche Zwecke möglich ist. Oder man vertraut das Autoloading direkt dem anbietenden Framework seiner Wahl an, beispielsweise Zend::Loader.

Autloading bringt die größten Performancegewinne dadurch, dass wirklich nur die Klassen geladen, geparst und verfügbar gemacht werden, die durch die Codeausführung wirklich benötigt werden.

Dazu gibts sogar schon Artikel: http://aktuell.de.selfhtml.org/weblog/php-autoload

- Sven Rautenberg

[Checklor]

Hallo.

Das Problem ist aber das bisher die Requests in den Konstruktoren der Klasse abgefragt werden.

Bsp:

include('class.settings.php');
$set_settings=new settings();
include('class.db.php'); // Wird nicht initialisiert weil statisch
include('class.utilities.php'); // Wird nicht initialisiert weil statisch
include('class.errorhandling.php'); // Wird nicht initialisiert weil statisch
include('class.contact.php');
$contact=new contact();
include('class.auth.php');
$auth=new auth();

So sieht der Kopf der index.php aus.
Wenn jetzt vom Kontaktformular eine Nachricht abgeschickt wird, steht im action="index.php" und er lädt die Seite neu, die Konstruktoren werden neu geladen und irgendwo steht jetzt drin "if REQUEST kontaktformular RUFE methode XY auf".

D.h. wenn ich sie erst später nachlade, müsste ich das Abfangen der Requests auslagern. Und dafür müsste ich meiner Ansicht nach jetzt in jedem Formular ein hidden-input-Feld machen mit dem Inhalt "Name der benötigten Klasse TRENNZEICHEN Name der benötigten Methode".

Das hast du ja als unsicher angemerkt, nachvollziehbar irgendwie. Aber mir fällt keine andere Lösung ein. __autoload läd sie erst nach wenn ich dieses ganze abfangen in die index.php packen würde, dann würde ich zwar beim inkludieren sparen, allerdings nicht an Schleifen(If-Abfragen in dem Fall).

Ich möchte allerdings an beidem sparen.

So long,

Checklor

[Sven Rautenberg]

Moin!

Das Problem ist aber das bisher die Requests in den Konstruktoren der Klasse abgefragt werden.

Ich sehe jetzt in dem Beispiel nicht, wo das Problem sein soll.

Bsp:

include('class.settings.php');
$set_settings=new settings();
include('class.db.php'); // Wird nicht initialisiert weil statisch
include('class.utilities.php'); // Wird nicht initialisiert weil statisch
include('class.errorhandling.php'); // Wird nicht initialisiert weil statisch
include('class.contact.php');
$contact=new contact();
include('class.auth.php');
$auth=new auth();

Mit Autoloading sähe der Code so aus:

include('autoloader.php');  
$set_settings=new settings();  
$contact=new contact();  
$auth=new auth();  

Statische Klassen werden auch automatisch geladen, wenn sie gebraucht werden.

Wenn jetzt vom Kontaktformular eine Nachricht abgeschickt wird, steht im action="index.php" und er lädt die Seite neu, die Konstruktoren werden neu geladen und irgendwo steht jetzt drin "if REQUEST kontaktformular RUFE methode XY auf".

Zu diesem Zeitpunkt wird die Klasse, die die Methode anbietet, ja schon als Objekt instanziiert worden sein, alternativ statisch aufgerufen. Ich sehe nicht, was da gegen Autoloading spräche.

D.h. wenn ich sie erst später nachlade, müsste ich das Abfangen der Requests auslagern. Und dafür müsste ich meiner Ansicht nach jetzt in jedem Formular ein hidden-input-Feld machen mit dem Inhalt "Name der benötigten Klasse TRENNZEICHEN Name der benötigten Methode".

Vollkommen falsch. DU lädst sie nicht "später" nach, sondern du definierst den Autoload-Mechanismus genau dafür, dass du die Klasse nicht "kurz vorher" vor ihrer ersten Benutzung manuell nachladen mußt.

Das hast du ja als unsicher angemerkt, nachvollziehbar irgendwie. Aber mir fällt keine andere Lösung ein. __autoload läd sie erst nach wenn ich dieses ganze abfangen in die index.php packen würde, dann würde ich zwar beim inkludieren sparen, allerdings nicht an Schleifen(If-Abfragen in dem Fall).

Ich möchte allerdings an beidem sparen.

Ich sehe das Problem nicht. Dein Code muß tun, was zu tun ist. Wenn du eine Abfolge von IF-Tests programmiert hast, um das Ergebnis zu erhalten, dann muss das offenbar so sein. Dieser Teil wird definitiv kein Performance-Problem aufwerfen.

Wenn dir dein Code nicht gefällt, dann wäre eine Runde Refactoring angesagt. Das hat aber nichts mit Autoloading zu tun.

- Sven Rautenberg

[Checklor]

Mit Autoloading sähe der Code so aus:

include('autoloader.php');

$set_settings=new settings();
$contact=new contact();
$auth=new auth();

>   
> Statische Klassen werden auch automatisch geladen, wenn sie gebraucht werden.  
  
  
Das ist mir schon klar das dies so aussehen würde. Allerdings habe ich dann das gleiche Problem wie vorher, oben müssen die die Klassen instanziert werden.  
  
Ne Klasse ist bei mir immer so aufgebaut (PSEUDO):  
  
~~~php
class Klasse1{  
  
public function __construct(){  
  
   if(isset($_POST['formular1'])) self::bearbeiteFormular1();  
   if(isset($_POST['formular2'])) self::bearbeiteFormular3();  
   if(isset($_POST['formular3'])) self::bearbeiteFormular3();  
}  
  
private static function bearbeiteFormular1(){}  
private static function bearbeiteFormular2(){}  
private static function bearbeiteFormular3(){}  
  
}

Also. Um auf ein Formulareingabe zu reagieren, _muss_ die Klasse schon vorher instanziert sein, damit im Konstruktor auf den Request passend reagiert werden kann. Das Autoloading kann ja nicht eingreifen weil PHP nicht automatisch weiß was ein Request für eine Klasse benötigt. Das muss ich ihm ja sagen.

Bei 10 Klassen mit jeweils mindestens 3 Request-Handlings im Konstruktor wären das bei jedem Request 30 If-Schleifen die durchfahren werden.

Nun will ich das Autoloading irgendwie nutzen.
Da gäbe es dann z.B. die Möglichkeite, jedem Formular ein hidden-input Feld zu geben mit einem Namen des Formulars. Dann könnte ich das so machen das Anfang der index.php eine große Schleifenkonstruktion steht die die Klassen je nach hidden-Input-Feld instanziert und da kann dan Autoloading eingreifen.

Das sähe so aus(PSEUDO):

if(isset($_POST['formular1']))  
{  
  $Klasse1 = new Klasse1();  
}  
elseif(isset($_POST['formular2'])) {  
  $Klasse2 = new Klasse2();  
}  
elseif(isset($_POST['formular3'])) {  
  $Klasse3 = new Klasse3();  
}  

Das würde zumind. schonmal aus 30 Requests Handlings 10 machen und nicht direkt alle Klassen includen. Wäre schonmal ein Erfolg.
Schade nur das mir das irgendwie null gefällt vom Aufbau, es sieht so prozedual aus, ich würde das viel lieber universeller, globaler, unabhängiger machen - OOP.
Ich muss ja jedes mal wenn eine Klasse dazu kommt, diese in diese "Liste" einreihen.

Liebe Grüße,

Checklor

[Tom]

Hello,

public function __construct(){

if(isset($_POST['formular1'])) self::bearbeiteFormular1();
   if(isset($_POST['formular2'])) self::bearbeiteFormular3();
   if(isset($_POST['formular3'])) self::bearbeiteFormular3();
}

Du hast den Aufruf der Bearbeitungsfunktion in die falsche Ebene gelegt.
Im Konstruktor muss nur die passende Methode (z.B. "work()" ) mit dem entsprechenden Formular geladen werden.

Der Aufruf findet aber im Wrapper der Klasse statt.

$class->work();

Dann kannst Du Dir auch statische Klassen sparen.

#---------
Das ist ja seit langem meine Rede:

Wer nur mit statischen Klassen arbeitet, nutzt die OOP nur um der OOP Willen und sollte besser weiterhin imperativ (prozdedural) programmieren.

Aufgrund des Gesamtkonzeptes von PHP und da es eine Interpreter-Sprache ist, kann die klassische Programmierung ohnehin schon verhältnismäßig objektorientiert verwendet werden. Der Aufruf von Funktionen findet auch zur Laufzeit über Namen statt und deren Vorhandensein kann man abfragen. Außerdem kann man auch mit "Array of Functions" arbeiten, also die zuständigen Funktionen erst zur Laufzeit in den Platzhalter einsetzen. Das nennt man dann wohl "späte Bindung" ...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Checklor]

Hello,

»» public function __construct(){
»»
»»    if(isset($_POST['formular1'])) self::bearbeiteFormular1();
»»    if(isset($_POST['formular2'])) self::bearbeiteFormular3();
»»    if(isset($_POST['formular3'])) self::bearbeiteFormular3();
»» }
Du hast den Aufruf der Bearbeitungsfunktion in die falsche Ebene gelegt.
Im Konstruktor muss nur die passende Methode (z.B. "work()" ) mit dem entsprechenden Formular geladen werden.

Der Aufruf findet aber im Wrapper der Klasse statt.

$class->work();

Du meinst ich sollte die IF Abfragen ausser halb von class Klasse1{} legen?
Dann muss ich die Dateien auch inkludieren damit die passenden Methoden für die Requests aufgerufen werden können. Ansonsten verstehe ich nicht was du meinst.

Liebe Grüße.

[Tom]

Hello,

Du meinst ich sollte die IF Abfragen ausser halb von class Klasse1{} legen?

Nein, ich meine, dass Du Klassenvariablen laden sollst abhängig von den benutzten Formularen.

Der _Aufruf_ der gesetzten Methode findet dann außerhalb statt und zwar immer nur durch

$class->work();  ### oder wie Du die Methode nennst.

egal, um welches Formular es sich handelt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Der Aufruf findet aber im Wrapper der Klasse statt.

$class->work();

bei nochmaligem Nachdenken komme ich zu dem Schluss, dass das nun langsam konzeptionell für Dein Gesamtkustwerk wird. Da könnte es sein, dass Sven Recht hat. Ich weiß zwar nicht, was er mit dem Begriff "Refactoring" meint, aber ich stelle es mir auf deutsch so vor, dass Du nochmal von vorne anfangen sollst.

Das Ganze schreit nach Polymorphie und virtuellen Methoden in einer Basisklasse für die Formularbearbeitung. Diese wird wohl auch schon ein Ableger einer Basisklasse für die Requestbearbeitung sein müssen.

In den Formularklassen sind dann aber die Standardmethoden "work()" [einfach mal von mir so genannt] und diversse Informationsmethoden zu implementieren. Deklariert werden sis bereits in der Formular-Basisklasse.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

bei nochmaligem Nachdenken komme ich zu dem Schluss, dass das nun langsam konzeptionell für Dein Gesamtkustwerk wird. Da könnte es sein, dass Sven Recht hat. Ich weiß zwar nicht, was er mit dem Begriff "Refactoring" meint, aber ich stelle es mir auf deutsch so vor, dass Du nochmal von vorne anfangen sollst.

Refactoring wird definiert als das Verändern von internem Code, ohne dabei das Verhalten des Interfaces zu verändern.

Könnte man ja mal bei Wikipedia nachschlagen. :)

Allerdings: Ja, vermutlich sind in diesem Projekt schon so viele Dinge in die falsche Richtung gelaufen, dass die Zeit für das Umarbeiten des bestehenden Codes kaum kürzer wäre, als ein Neuanfang. Allerdings: Umarbeiten, ggf. auch einzelne Teile neuschreiben, ist sicher die bessere Lösung, als nochmal ganz von vorn zu beginnen.

Das Ganze schreit nach Polymorphie und virtuellen Methoden in einer Basisklasse für die Formularbearbeitung. Diese wird wohl auch schon ein Ableger einer Basisklasse für die Requestbearbeitung sein müssen.

Ich glaube nicht, dass diese "Kanonen" schon rausgerollt werden müssen oder sollten. Dazu ist offensichtlich im Moment noch zuviel "schräg" realisiert. Das sollte erst einmal vereinfacht werden.

- Sven Rautenberg

[Tom]

Hello,

bei nochmaligem Nachdenken komme ich zu dem Schluss, dass das nun langsam konzeptionell für Dein Gesamtkustwerk wird. Da könnte es sein, dass Sven Recht hat. Ich weiß zwar nicht, was er mit dem Begriff "Refactoring" meint, aber ich stelle es mir auf deutsch so vor, dass Du nochmal von vorne anfangen sollst.

Refactoring wird definiert als das Verändern von internem Code, ohne dabei das Verhalten des Interfaces zu verändern.

Könnte man ja mal bei Wikipedia nachschlagen. :)

Hab ich doch. Ist aber genauso ein Begriff, wie mein von Christian bemängeltes "academic locking" (Sperren mit Verzögerun)...

Manchmal ist es einfach schöner, wenn wir hier (auch) noch deutsch reden. Das soll nicht heißen, dass man für längere fachliche Sachverhalte nicht einen treffenden Kurzbegriff finden sollte!

:-)

Allerdings: Ja, vermutlich sind in diesem Projekt schon so viele Dinge in die falsche Richtung gelaufen, dass die Zeit für das Umarbeiten des bestehenden Codes kaum kürzer wäre, als ein Neuanfang. Allerdings: Umarbeiten, ggf. auch einzelne Teile neuschreiben, ist sicher die bessere Lösung, als nochmal ganz von vorn zu beginnen.

Die Groblösung fühlt sich hier beim Lesen aber schon wesentlicher angenehmer an, als ganz viele andere vorgestellte Ideen anderer Poster. Checklor sollte sich also nicht kopfscheu machen lassen und seine bisherigen Ansätze nicht einfach wegschmeißen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Das ist mir schon klar das dies so aussehen würde. Allerdings habe ich dann das gleiche Problem wie vorher, oben müssen die die Klassen instanziert werden.

Wenn ich mir in deinem Anfangsposting die Klassenauflistung so ansehe, bin ich sowieso der Meinung, dass diese Klassen jeweils viel zuviel tun.

Nur mal so als herausgegriffenes Beispiel: Eine Klasse "Blog" - was tut die bei dir? Alles im Blog? Oder wieviele Unterklassen werden durch diese Klasse aufgerufen?

Ne Klasse ist bei mir immer so aufgebaut (PSEUDO):

class Klasse1{

public function __construct(){

if(isset($_POST['formular1'])) self::bearbeiteFormular1();
   if(isset($_POST['formular2'])) self::bearbeiteFormular3();
   if(isset($_POST['formular3'])) self::bearbeiteFormular3();
}

private static function bearbeiteFormular1(){}
private static function bearbeiteFormular2(){}
private static function bearbeiteFormular3(){}

}

  
Das ist alles andere als OOP. Wozu brauchst du Klassen? Als Namespace-Separator vielleicht, aber das war es dann auch.  
  

> Also. Um auf ein Formulareingabe zu reagieren, \_muss\_ die Klasse schon vorher instanziert sein, damit im Konstruktor auf den Request passend reagiert werden kann. Das Autoloading kann ja nicht eingreifen weil PHP nicht automatisch weiß was ein Request für eine Klasse benötigt. Das muss ich ihm ja sagen.  
  
Das Problem ist, dass du die Klasse instanziierst, damit der Konstruktor aufgerufen wird, danach aber nur statische Methoden benutzt. Entscheide dich mal: Entweder eine Klasse wird als Objekt instanziiert, dann sind ihre Methoden nicht statisch, und es macht in der Logik der Applikation auch Sinn, dass es von einundderselben Klasse mehr als ein Objekt parallel im gleichen Skriptkontext gibt. Beispiel dafür wäre beispielsweise ein Array von "Kommentarobjekten" in einem "Blogeintragobjekt".  
  
Alternativ ist eine Klasse durchgehend statisch. Dann hat sie nicht mehr viel von OOP, sondern dient eigentlich nur noch dazu, die prozedurale Vorgehensweise mit freundlicher klingenden Namespaces zu verschönern, aber für gewisse Hilfsfunktionen, die man zentralisiert anbieten will, ist das durchaus erlaubt. Nur sollte nicht der gesamte Code daraus bestehen.  
  

> Bei 10 Klassen mit jeweils mindestens 3 Request-Handlings im Konstruktor wären das bei jedem Request 30 If-Schleifen die durchfahren werden.  
  
Es gibt keine If-Schleifen.  
  
Und für die Realisierung des Request-Handlings bist du ja selbst verantwortlich. dedlfix hat dazu ja auch einen Kommentar abgegeben, der genau in die richtige Richtung zielt. Mache dich mit dem MVC-Pattern vertraut. Nutze ein Framework, das dir zu diesem Zweck die meiste Nerv-Arbeit abnehmen kann. MVC zu realisieren ist eine recht langweilige Standardaufgabe, die viel Zeit schluckt, wenn man sie selbst realisieren will, ohne nennenswerte Vorteile gegenüber bestehenden Frameworks zu bieten.  
  

> Nun will ich das Autoloading irgendwie nutzen.  

[...]  

> Schade nur das mir das irgendwie null gefällt vom Aufbau, es sieht so prozedual aus, ich würde das viel lieber universeller, globaler, unabhängiger machen - OOP.  
  
Tja, das Problem dürfte insgesamt eher in der Tatsache begründet liegen, dass dein bisheriger Ansatz des Request-Parsings suboptimal ist, und du ohne größere Umbauten aus dieser Falle auch nicht herauskommst. Abgesehen vom ebenfalls suboptimalen Einsatz von OOP.  
  
 - Sven Rautenberg

[Klaus / Checklor]

Nur mal so als herausgegriffenes Beispiel: Eine Klasse "Blog" - was tut die bei dir? Alles im Blog? Oder wieviele Unterklassen werden durch diese Klasse aufgerufen?

Wenn ich ehrlich bin - ja.
z.b. meine Newsletter Klasse, sie macht _alles_ sie erstellt die Tabellen in der Datenbank falls sie noch nicht vorhanden sind, sie hat sämtliche Funktionen wie. Newsletter als Entwurf speichern, ENtwurf ändern, Entwurf löschen, Entwurf verschicken, für den Newsletter eintragen, den Newsletter schreiben und direkt abschicken. Inklusive der Formular fürs "für den Newsletter eintragen", Etnwurfsänderung, Newsletter schreiben - das alles mit BB-Code-Unterstützung usw.. Sie hat 768 Zeilen ohne groß Abstände gemacht zu haben. Sie verarbeitet, holt, gibt aus und prüft. Ich dachte mir halt so wäre es das beste da ich wenn ich ein Projekt habe einfach nur die Datei inkluden muss und mir alles zur Verfügung steht.

Das ist alles andere als OOP. Wozu brauchst du Klassen? Als Namespace-Separator vielleicht, aber das war es dann auch.

In erster Linie dachte ich mir halt um eine Art "Moduldatenbank" zu haben.
Ich brauche was? Gut - ich kopiere mir einfach nur die eine Datei mit der einen Klasse aus meiner "Klassenbibliothek" und kann alles tun was ich brauche. Es ging mir halt um Wiederverwertbarkeit ohne das ich den ganzen prozedualen Code aus alten Projekten herraussuchen muss und ein wenig abändern muss.

Das Problem ist, dass du die Klasse instanziierst, damit der Konstruktor aufgerufen wird, danach aber nur statische Methoden benutzt. Entscheide dich mal: Entweder eine Klasse wird als Objekt instanziiert, dann sind ihre Methoden nicht statisch, und es macht in der Logik der Applikation auch Sinn, dass es von einundderselben Klasse mehr als ein Objekt parallel im gleichen Skriptkontext gibt. Beispiel dafür wäre beispielsweise ein Array von "Kommentarobjekten" in einem "Blogeintragobjekt".

Du hast Recht, war grad auch dumm das im Beispiel zu machen, meine Klassen halten sich eigendlich an diese Regeln bis auf 1 oder 2...

Alternativ ist eine Klasse durchgehend statisch.

Das habe ich nur bei ein Datenbankklasse udn Utlilityklasse gemacht weil ich mir denke - die brauchste echt _überall_ die kannste auch statisch machen. Ist das nicht okay?
Alternativ gab sich mir auch noch das Singleton-Pattern aber ich fand die statische Methode sinnvoller.

Und für die Realisierung des Request-Handlings bist du ja selbst verantwortlich. dedlfix hat dazu ja auch einen Kommentar abgegeben, der genau in die richtige Richtung zielt. Mache dich mit dem MVC-Pattern vertraut. Nutze ein Framework, das dir zu diesem Zweck die meiste Nerv-Arbeit abnehmen kann. MVC zu realisieren ist eine recht langweilige Standardaufgabe, die viel Zeit schluckt, wenn man sie selbst realisieren will, ohne nennenswerte Vorteile gegenüber bestehenden Frameworks zu bieten.

Ich habe mit Frameworks absolute Probleme. Von der Einstellung her.
Ich ich denke mir halt. Wenn ich mit Frameworks arbeite, geht mir der Lerneffekt absolut flöten. Ich _hasse_ es, fremde Zeilen zu benutzen. Es war halt immer so das ich dadurch das ich mir neue Ziele gesetzt habe - gelernt habe. Mir fehlt dann einfach die Motivation das zu ganze zu machen.
Ich mach z.Z. halt noch mein Abi, viel Sport, hab ne Freundin, geh am Wochenende gerne feiern usw. und da ich schnell anderes zu tun habe als mich vor den PC zu setzen und konzentriert Zeit mit mir, PHP und meinen Projekten die ich mir als Ziel setze zu machen. Zuvieles lenkt mich halt schnell mal ab. Seit ich 12 bin bzw von 12-17,5 Jahren habe
ich xhtml, css, php gelernt nur halt dummerweise die ganzen Jahre über prozedual. OOP erst seit nem halben Jahr etwa.

Klingt jetzt wie ne halbe Lebengeschichte aber da ich auch keinen einzigen habe mit dem ich mich über das "hobby" unterhalten kann usw brauch ich halt "schnelle Erfolge" im Sinne von. Kleine Hürde setzen - bezwingen.

Ganz zu Anfang war das zum Beispiel - "ich will das meine Seite in jedem Browser gleich aussieht", danach setzte ich mir dann das Ziel "jetzt soll es trotzdem W3C konform/valide sein. Und jetzt ist es halt erstmal gewesen, "ich möchte jede Sache nur einmal schreiben müssen und danach wiederverwerten können" und jetzt ist es nunmal "OOP gerecht optimieren" oder so ähnlich..
Wenn ich mir jetzt ein Framework schnappe ist meine Motivation im Keller.
Ich bin nicht mehr stolz darauf das ich dies und das geschafft habe - schließlich hat mir ja jemand anderes schon die Arbeit abgenommen und das Prinzip der ganzen Pattern und MVC usw ist mir dann immernoch nicht zu 100% nachvollziehbar.

Tja, das Problem dürfte insgesamt eher in der Tatsache begründet liegen, dass dein bisheriger Ansatz des Request-Parsings suboptimal ist, und du ohne größere Umbauten aus dieser Falle auch nicht herauskommst. Abgesehen vom ebenfalls suboptimalen Einsatz von OOP.

Das erstere ist ja mein Problem, ist ja auch das Thema hier.

Vllt. sollte ich mich auch nicht schämen soviele Fragen zu stellen denn das hier bin auch ich. Ich wollte halt nicht 20 Fragen hintereinander stellen.

- jetz komm ich mir grad vor wie ein kleiner Junge.

[Sven Rautenberg]

Moin!

»» Nur mal so als herausgegriffenes Beispiel: Eine Klasse "Blog" - was tut die bei dir? Alles im Blog? Oder wieviele Unterklassen werden durch diese Klasse aufgerufen?

Wenn ich ehrlich bin - ja.
z.b. meine Newsletter Klasse, sie macht _alles_ sie erstellt die Tabellen in der Datenbank falls sie noch nicht vorhanden sind, sie hat sämtliche Funktionen wie. Newsletter als Entwurf speichern, ENtwurf ändern, Entwurf löschen, Entwurf verschicken, für den Newsletter eintragen, den Newsletter schreiben und direkt abschicken. Inklusive der Formular fürs "für den Newsletter eintragen", Etnwurfsänderung, Newsletter schreiben - das alles mit BB-Code-Unterstützung usw.. Sie hat 768 Zeilen ohne groß Abstände gemacht zu haben. Sie verarbeitet, holt, gibt aus und prüft. Ich dachte mir halt so wäre es das beste da ich wenn ich ein Projekt habe einfach nur die Datei inkluden muss und mir alles zur Verfügung steht.

Ja klar, dieser Gedankenansatz "ein Include, und ich habe alles, was ich brauche" ist natürlich naheliegend, wenn man kein Autoloading kennt und auch keine endlosen require_once-Arien in den jeweiligen Dateien ausführen will.

Aber allein bei deiner Beschreibung fallen mir schon mal folgende Ansatzpunkte für eigenständige Klassen ein:

1. Eine Datenbankklasse. Sowas schreibt man auch nicht selbst, sondern wählt vorhandene Frameworks. Als untersten Einstieg vielleicht PDO - das arbeitet noch sehr direkt mit SQL auf der Datenbank. Alternativ gern auch ein ORM-Framework wie Doctrine. Das übersetzt deine Datenbankinhalte gleich direkt in Objekte, die du neu erstellen, verändern, speichern, laden etc. kannst, und realisiert auch die Verteilung von 1:n und n:m-Relationen.

2. Eine Formularklasse: Generieren, Daten validieren, Fehlerbehandlung, Datenweitergabe in die Applikation. Wie ausführlich die nun sein darf, ist Ansichtssache, aber beispielsweise liefert Zend_Form einen brauchbaren Ansatzpunkt.

3. BBcode kriegt man auch in Klassen realisiert, ohne selbst Code schreiben zu müssen.

4. Nicht ganz klar ist die Frage nach einer Template-Klasse, aber auch die wird mit Sicherheit benötigt. Es muß nicht unbedingt Smarty sein, auch der MVC-Ansatz z.B. im Zend-Framework ist sehr brauchbar.

5. Eine Klasse zum Mailen. Wobei die wiederum zerfällt in eine Klasse, die gegenüber der Anwendung die Mails entgegennimmt, und einer Arbeiterklasse, die konkret basierend auf der Konfiguration des Mailservers die eigentliche Mail rausschickt.

Und so weiter, und so fort...

Tja, eigentlich sind ganz viele dieser Sachen absolute Standardaufgaben, die man ohne Probleme einem Framework auf's Auge drücken sollte, weil es im Ergebnis viel bessere Resultate gibt, wenn man seine eigene Energie auf die Lösung des primären Anliegens aufwendet, und alles, was nur am Rande mit dieser Aufgabe zu tun hat, aber dennoch erledigt werden muss, von einer Codebasis machen lässt, um die sich viele engagierte Entwickler kümmern, die viel wahrscheinlicher schon alle möglichen und unmöglichen Probleme dabei erlebt und gefixt haben.

»» Alternativ ist eine Klasse durchgehend statisch.

Das habe ich nur bei ein Datenbankklasse udn Utlilityklasse gemacht weil ich mir denke - die brauchste echt _überall_ die kannste auch statisch machen. Ist das nicht okay?
Alternativ gab sich mir auch noch das Singleton-Pattern aber ich fand die statische Methode sinnvoller.

Das Singleton-Pattern wird sowieso überbeansprucht. Ich persönlich mag es überhaupt nicht, weil man es sehr schlecht testen kann. Außerdem ist es zum Glück nur in wirklich wenigen Fällen tatsächlich angebracht - dummerweise wird es aber viel häufiger benutzt, vermutlich weil die Programmierer als einziges Pattern "Singleton" behalten haben und es deshalb immer und immer wieder umsetzen... :)

Ich habe mit Frameworks absolute Probleme. Von der Einstellung her.
Ich ich denke mir halt. Wenn ich mit Frameworks arbeite, geht mir der Lerneffekt absolut flöten.

Sehe ich anders. Frameworks helfen dir, dich auf die wirklich wichtigen Dinge konzentrieren zu können, nämlich das, was deine Webanwendung wirklich ausmacht. Klar, wenn du vorher noch nie eine Datenbankklasse geschrieben hast, fühlt es sich blöd an, gleich ein Framework zu verwenden. Andererseits: Wenn du einmal eine Datenbankklasse geschrieben hast, die noch nicht so wahnsinnig ausgereift ist, und du hast ein zweites Projekt - warum dann deine alte DB-Klasse verwenden, warum nicht ein gutes, funktionierendes Framework einsetzen?

Ich _hasse_ es, fremde Zeilen zu benutzen.

Dafür gibts sogar eine Bezeichnung: "NIH-Syndrom" - "Not invented here". Lieber das Rad ein zweites Mal erfinden, anstatt bestehenden, funktionierenden Code eines anderen Herstellers einzusetzen.

Diese Einstellung ist nicht nur jungen Einzelkämpfern zu eigen, sondern kommt in den besten Entwicklerkreisen vor.

Klingt jetzt wie ne halbe Lebengeschichte aber da ich auch keinen einzigen habe mit dem ich mich über das "hobby" unterhalten kann usw brauch ich halt "schnelle Erfolge" im Sinne von. Kleine Hürde setzen - bezwingen.

Kommunikation über Programmieren kriegst du hier im Forum mehr als genug, würde ich meinen. Sowohl als theoretische Diskussion über den allgemein richtigen Ansatz, als auch ganz konkret zu Code, den du postest.

Wenn ich mir jetzt ein Framework schnappe ist meine Motivation im Keller.

Warum dieses? Schließlich nutzt du ja schon ein "Framework", welches dich mit sehr vielen Funktionen versorgt: PHP. Was spricht dagegen, sich noch mit mehr Funktionen versorgen zu lassen, um etliche lästige Standardaufgaben zu eliminieren.

Auch mit Framework bleiben zahlreiche herausfordernde Programmieraufgaben zurück - nämlich alle diejenigen, die die Individualität der Software ausmachen.

Ich bin nicht mehr stolz darauf das ich dies und das geschafft habe - schließlich hat mir ja jemand anderes schon die Arbeit abgenommen und das Prinzip der ganzen Pattern und MVC usw ist mir dann immernoch nicht zu 100% nachvollziehbar.

Dass eine Menge zu Lernen ist, dagegen dürfte kein Kraut gewachsen sein.

Die Sache ist aber die: Wenn du schon so lange dabei bist, und jetzt auch vor OOP nicht zurückgeschreckt bist, nehme ich mal stark an, dass dir vorschwebt, das auch beruflich zu tun. Aber kein Kunde zahlt dir jedes Mal den Extra-Aufwand, für ihn ein individuelles Framework an Standardaufgabenlösungen zu implementieren - auch wenn du "dein" Framework dann jedesmal wieder zum Einsatz bringen könntest, irgendwelche Änderungen werden doch notwendig sein.

Und insbesondere wenn du mit Kollegen am Projekt zusammenarbeitest, bzw. der Kunde und/oder Chef befürchten muss, dass du als Kenner deines Frameworks nicht unendlich zur Verfügung stehen kannst, sondern irgendwann weg bist, wird die Abwägung zwischen einem speziellen Framework von dir oder einem globalen Open-Source-Framework mit zahlreichen aktiven Entwicklern sowieo weiteren zahlreichen Nutzern eindeutig in Richtung des bekannten, öffentlichen Frameworks ausgehen. Gehe also mal davon aus, dass du im Job zwangsläufig den Kontakt mit den wichtigen Frameworks haben wirst.

Vllt. sollte ich mich auch nicht schämen soviele Fragen zu stellen denn das hier bin auch ich. Ich wollte halt nicht 20 Fragen hintereinander stellen.

Tja, wenn du eine generelle Einschätzung zu deinem derzeitigen Projektcode haben willst, kommst du kaum umhin, nennenswerte Teile des Codes offenzulegen, um eine Inspektion zu ermöglichen.

Alternativ: Es gibt hier im Forum aktuell immer häufiger Diskussionen zu genau diesem Themenbereich: PHP OOP. Es ist nie falsch, die Diskussionen zu verfolgen und durch eigene Gedanken anzureichern. Es kann dir nichts besseres passieren, als wenn in so einer Diskussion deine Ansätze mit Begründung korrigiert werden. Das zweitbeste: Wenn sie sich als brauchbar erweisen. :)

- Sven Rautenberg

[Klaus / Checklor]

Danke für deine Ausführungen.
Ja vllt hast du Recht und ich sollte mir Zend wirklich mal reinziehen.
Ich bin mal gespannt wie lange es dauert bis ich damit nen Forum hinbekomme.
Zend stellt mir ja sämtliche Funktionen zur Verfügung aber doch keine fertigen "Projekte" oder?
Sprich ich muss doch immernoch ein MVC Pattern auf die Beine stellen, nur ich lasse mir ein wenig Arbeit abnehmen indem ich fertige Funktionen fürs Abrufen von Daten aus einer Datenbank nutze.
Wie darf ich Zend deiner Meinung nach verstehen und nutzen?

Tja, wenn du eine generelle Einschätzung zu deinem derzeitigen Projektcode haben willst, kommst du kaum umhin, nennenswerte Teile des Codes offenzulegen, um eine Inspektion zu ermöglichen.

Damit habe ich überhaupt kein Problem.
Ich kann ja mal meine Newsletterklasse posten.
Vorsicht wird lang :D...
Die Utility, Datenbank und Settingsklasse(hier wird eine ini geparst mit den wichtigsten Einstellungen) lasse ich mal draussen...

Okay sie passt nicht hier rein "Sie sind wohl etwas geschwätzig?" ^^...
Ich poste es extra.

[Klaus]

Okay auch hier passt es nicht rein ohne sonsitgen Text.

Schau mal hier ich hab es bei Nopaste.org gepostet.

Lg, Klaus

[Sven Rautenberg]

Moin!

Ich bin mal gespannt wie lange es dauert bis ich damit nen Forum hinbekomme.
Zend stellt mir ja sämtliche Funktionen zur Verfügung aber doch keine fertigen "Projekte" oder?
Sprich ich muss doch immernoch ein MVC Pattern auf die Beine stellen, nur ich lasse mir ein wenig Arbeit abnehmen indem ich fertige Funktionen fürs Abrufen von Daten aus einer Datenbank nutze.
Wie darf ich Zend deiner Meinung nach verstehen und nutzen?

Zend liefert dir zahlreiche Einzelteile, die zwar auch allesamt gemeinsam genutzt werden können, aber nicht müssen.

Eines dieser Teile ist das MVC-Pattern. Zend geht von einer Standard-Verzeichnisstruktur aus (ist natürlich änderbar, aber das will man eigentlich nicht), in der sich alle typischen Komponenten eines MVC befinden: Models, Views und Controller. Die Controller regeln jeweils, welcher View angezeigt wird, und ziehen ggf. Daten aus den Models dazu heran. Die Models regeln ihrerseits, wie sie die Daten besorgen, die da angefordert werden. Das _kann_ man mit Zend_Db machen, andere DB-Adapter gehen aber genauso gut oder besser, wenn man nicht so auf dem ActiveRecord-Pattern steht.

Das Zend-Framework liefert dir jedenfalls zahlreiche nützliche Klassen, die meistens abgekapselt nur für sich nutzbar sind, aber gerade auch im Zusammenspiel noch extrem an Wert gewinnen können. Beispielsweise liefert Zend_Config den Zugang zu Konfigurationsdateien in vielen Formaten, z.B. INI-Dateien, XML oder auch schlichten PHP-Arrays. Damit kann man auf seine Konfiguration schon recht vernünftig zugreifen. Der Clou ist: Viele andere Zend-Komponenten erlauben es, die Konfigurationsparameter auch als Zend_Config-Objekt zu erhalten - man muß also nicht erst separat die Parameter auspacken und umkopieren in ein neues Array.

»» Tja, wenn du eine generelle Einschätzung zu deinem derzeitigen Projektcode haben willst, kommst du kaum umhin, nennenswerte Teile des Codes offenzulegen, um eine Inspektion zu ermöglichen.

Damit habe ich überhaupt kein Problem.
Ich kann ja mal meine Newsletterklasse posten.

Ich werde wohl heute dazu keinen Kommentar mehr abgeben können, aber ich gucke garantiert rein.

- Sven Rautenberg

[Klaus]

Aber ab wann lohnt es sich das Framework einzusetzen?
Ich meine. Wenn man ein Framework benutzt, dann baut man das KOMPLETTE Projekt darauf auf - oder man lässt es ganz bleiben oder?

Ich werde wohl heute dazu keinen Kommentar mehr abgeben können, aber ich gucke garantiert rein.

Lass dir Zeit, aber deine Meinung darüber wäre mir trotzdem sehr wichtig!

Ausserdem ist meine Erstfrage irgendwie nicht klar beantwortet. Bzw. halb.
Also die Requests werden im FrontController "ausgewertet" und die passenden Methoden/Klassen dann aufgerufen. Das sehe ich so richtig oder?
Also kommen in den Frontcontroller dann IF-Abfragen, um zu checken was für ein Requests es ist und dann wird passend gehandelt.

lg

[Tom]

Hello,

Also kommen in den Frontcontroller dann IF-Abfragen, um zu checken was für ein Requests es ist und dann wird passend gehandelt.

Nein. Wenn DU sauber objektorientiert programmierst, brauchst Du keine Bedingungsausscheidung für die Methoden mehr. Lediglich für die Klasse würde ich aus Sicherheitsgründen eine machen. Alternativ könntest Du schreiben (was aber so aber ggf. gefährlich ist!, darüber muss man nochmal nachdenken, aber das hat Christian Seiler ja schon in seinem Artikel getan *g*):

if (isset($_POST['btn']) and is_array($_POST['btn']))
{
    $classname = key($_POST['btn']);

$class = new $classname();

$class->work();

}

Mehr musst Du nicht mehr schreiben. Alles andere würde dann durch den Autoloader veranlasst. Da alle Deine Klassen von einer Masterklasse abstammen, haben sie auch alle die Methode work() implemnentiert.

Da immer nur eine dieser Arbeitsklassen und in dieser nur eine Formularklasse gleichzeitig aktiv sein kann (es dürften mehrere, Singelton ist also hier falsch), wird der Baum bereits mit der Instantiierung der Arbeitsklasse gepflanzt.

Die Arbeitsklasse (2. Stufe Eingangscontroller) überprüft dann automatisch das weitere $_POST['btn']-Array und instantiiert die $form-Instanz. usw.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Klaus]

Hi.

if (isset($_POST['btn']) and is_array($_POST['btn']))
{
    $classname = key($_POST['btn']);

$class = new $classname();

$class->work();

}

Wir wären also wieder bei der Anfanglösung, das Auswerten eines Input-Hidden / Submit Namens und dem Einwand Rautenbergs eine Information klassenbetreffend o.ä. in den offenen HTML Code zu legen.

P

Liebe Grüße und einen schönen Sonntag!

[Tom]

Hello,

if (isset($_POST['btn']) and is_array($_POST['btn']))
{
     $classname = key($_POST['btn']);

$class = new $classname();

$class->work();

}

Wir wären also wieder bei der Anfanglösung, das Auswerten eines Input-Hidden / Submit Namens und dem Einwand Rautenbergs eine Information klassenbetreffend o.ä. in den offenen HTML Code zu legen.

Was ja aber bei entsprechender Kontrolle im Autolader überhaupt kein Problem bedeutet.
Irgendwann muss der Client ja mal sagen dürfen, was er will. Ob Du das nun mit einer Transformation erst noch verschlüsselst oder im Quasi-Klartext (ist ja uch nur ein Name...) in den HTML-Code schreibst, das ist doch wurscht.

Bei mir funktioniert das auf diese Weise jedenfalls bestens.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

echo $begrüßung;

Aber ab wann lohnt es sich das Framework einzusetzen?

Das kann man so pauschal nicht sagen. Für ein einfaches Kontaktformular lohnt es sicher nicht. Für ein Gästebuch vielleicht auch nicht. Ebenso kann man ein Blog oder ein Forum ohne Framework aufsetzen. Aber wenn du mehrere Dinge kombinieren willst und ein Wachstumsende der Website nicht abzusehen ist, dann lohnt sich ein Framework schon. Es wird viele Dinge geben, die für alle Teilapplikationen gleichermaßen ausgeführt werden müssen. Die wirst du sicher/hoffentlich nicht mit Copy&Paste vervielfachen. Du wirst dir also selbst eine Art Framework schreiben. Oder du greifst auf das zurück, was andere bereits mehr oder weniger perfekt vorgearbeitet haben.

Ich meine. Wenn man ein Framework benutzt, dann baut man das KOMPLETTE Projekt darauf auf - oder man lässt es ganz bleiben oder?

Das wäre sinnvoll.

Also die Requests werden im FrontController "ausgewertet" und die passenden Methoden/Klassen dann aufgerufen. Das sehe ich so richtig oder?

Ja, der Front Controller ist die Instanz, die alle Requests einer Anwendung (außer statischen Ressourcen) entgegennimmt und zwecks Ausführung passend delegiert.

Also kommen in den Frontcontroller dann IF-Abfragen, um zu checken was für ein Requests es ist und dann wird passend gehandelt.

Kann man machen. Niemand schreibt vor, wie man den Routingmechanismus implementieren muss. Das kann man mit einem Haufen if-Abfragen lösen oder mit einem switch-Statement oder mit dem Autoload-Mechanismus oder ... was auch immer man für angemessen hält.

echo "$verabschiedung $name";

[Tom]

Hello,

Ja, der Front Controller ist die Instanz, die alle Requests einer Anwendung (außer statischen Ressourcen) entgegennimmt und zwecks Ausführung passend delegiert.

Wobei der Front-Controller sich in PHP darauf beschränken kann festzustellen, ob es überhaupt Steuerinformationen gibt, oder ob die ressource generisch angefordert wurde.

In einer Sprache, die Superglobale Variablen kennt, gibt es keine starke Trennung zwischen VCM (View - Controller - Model, in der Reihenfolge der Inanspruchnahme). Außerdem ist der Controller in einer Client-Server-Applikation zweigeteilt und man müsste nun erst entscheiden, welcher Teil des Controllers benutzt wurde. Der des Servers überwacht übrigens den des Clients bei Kommunikationsrichtung Client -> Server und macht ihm Vorgaben bei Kommunikationsrichtung Server -> Client.

Kann man machen. Niemand schreibt vor, wie man den Routingmechanismus implementieren muss.

Aber die OOP schreibt vor, dass es diese imperative Vorgehensweise zugunsten der Selbstbestimmung der freien Objekte nicht mehr gibt! ( es war gerade 1. Mai *gg* ).

Kombiniert man PHP-OOP und die Superglobalen Variablen optimal und vergisst nicht, dass ein Script nicht ewig lebt[1], wird der Code plötzlich superschlank und beschränkt sich auf die Abbildung der fachlichen Hierarchie. Alles andere regeln die Objekte selber.

[1] es ist ja quasi selber nur eine Instanz des PHP-Runtime, die die vorhandenen Methoden ihrer "Runtime-Klasse" nutzt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

echo $begrüßung;

» Ja, der Front Controller ist die Instanz, die alle Requests einer Anwendung (außer statischen Ressourcen) entgegennimmt und zwecks Ausführung passend delegiert.
Wobei der Front-Controller sich in PHP darauf beschränken kann festzustellen, ob es überhaupt Steuerinformationen gibt, oder ob die ressource generisch angefordert wurde.

Auch ein GET / HTTP/1.1 enthält Steuerinformation. (Wie man daraus ermittelt, dass die Index-Action des Home-Controllers aufzurufen ist, steht auf einem anderen Blatt.) Was du allerdings mit generisch angeforderten Ressourcen meinst, weiß ich nicht.

In einer Sprache, die Superglobale Variablen kennt, gibt es keine starke Trennung zwischen VCM (View - Controller - Model, in der Reihenfolge der Inanspruchnahme).

Auch hier entzieht es sich meinem Verständnis, was du für einen Einfluss von superglobalen Variablen auf das MVC-Muster siehst. Auch gibt es zwischen M, V und C keine Reihenfolge. Es ist eher ein unten offenes Dreieck. Oben steht der Controller, der Daten zwischen Model und View vermittelt, wobei auch noch das Model optional ist.

Außerdem ist der Controller in einer Client-Server-Applikation zweigeteilt und man müsste nun erst entscheiden, welcher Teil des Controllers benutzt wurde. Der des Servers überwacht übrigens den des Clients bei Kommunikationsrichtung Client -> Server und macht ihm Vorgaben bei Kommunikationsrichtung Server -> Client.

Der Client ist uninteressant. Die Kommunikationsströme zwischen Client und Server sind in einer weiter oben gelagerten Schicht angesiedelt, die für die derzeitige Betrachtung keine Rolle spielt. Für den Webserver gibt es einen Request und ein Response. Auch gelangt der Request nicht direkt zum einem ActionController. Der FrontController, der gern für das Vermitteln der Requests verwendet wird, ist kein Bestandteil des MVC-Patterns.

» Niemand schreibt vor, wie man den Routingmechanismus implementieren muss.
Aber die OOP schreibt vor, dass es diese imperative Vorgehensweise zugunsten der Selbstbestimmung der freien Objekte nicht mehr gibt! ( es war gerade 1. Mai *gg* ).

Was du meinst ist die Anarchie der Wald- und Wiesenscripte. Der FrontController jedenfalls ist Diktatur.

Kombiniert man PHP-OOP und die Superglobalen Variablen optimal und vergisst nicht, dass ein Script nicht ewig lebt[1], wird der Code plötzlich superschlank und beschränkt sich auf die Abbildung der fachlichen Hierarchie. Alles andere regeln die Objekte selber.

Es gibt immer Alternativen, auch zum MVC-Pattern. Die Frage ist nur, wie man sein Projekt strukturiert. Pattern sind die Beschreibung einer Vorgehensweise. Man braucht keine OOP um sie zu implementieren. Man muss sie auch nicht unbedingt kennen. Ein switch in der index.php, auf die per mod_rewrite alle Requests geleitet werden, und das die Abarbeitung an einzelne Scripte delegiert, ist bereits ein FrontController.

echo "$verabschiedung $name";

[Checklor]

Allerdings würde ich das bei OOP nicht per Switch machen, sondern durch entsprechende Zuweisung an eine Funktionsvariable.

Wie meinen?

Die Klasse wird ja nur benötigt, wenn eine ihrer Methoden vom User angefragt wurde.
Wenn sie angefragt wurde, wird die passende Klasse included.
Und wenn deren weitere Prüfung ergibt, dass die Aktion zum Formular passt und aufgrund der Vorgangsdaten in der Session jetzt auch sinnvoll ist, dann wird sie ausgelöst.

WEnn Du das nach außen nicht offen elegen willst, welcher Button zu welcher Klasse gehört, kannst Du natürlich auch eine Transformationstabelle zwischenschalten.

btn[23489067564] gehört dann eben zu Klasse 'xyz' und zu Formular 'doedelblah'.

Sorry irgendwie blicke ich nicht ganz durch...
Könntest dus nochmlal genauer erklären was dumeinst?

lg

[Checklor]

if(isset($_POST)){
   include(btn[0]);
}

Das klappt irgendwie nicht.

Es müsste ja heißen: include($_POST[btn[0]])

aber er will ein $_POST[''] haben. Erst $_POST["btn[0]"] nimmt er, aber dann ist es nicht mehr richtig.

Also irgendwie auch logisch denn, er will ja den Wert btn[0] vom Formular haben. Dieser Button ist aber ein Submit Button und btn[0] gibt es eh nicht alleine. Er weißt also dann den Wert des Submit Buttons zu und das wäre "Abschicken" und nicht "Newsletter".

[Sven Rautenberg]

Moin!

Das klappt irgendwie nicht.

Es müsste ja heißen: include($_POST[btn[0]])

Du willst NIEMALS eine include-Anweisung mit einem vollständig dynamischen Pfad in deine Skripte schreiben! Das ist ein Einfallstor für Code-Injection böser Angreifer. Erst recht willst du es den Angreifern nicht so leicht machen und direkt den Inhalt von $_GET, $_POST, $_COOKIE oder sonst einer vom Benutzer beeinflussbaren Variable dort nutzen.

Lies meine Anmerkung zum Autoloading.

- Sven Rautenberg

[dedlfix]

echo $begrüßung;

D.h. also wenn ich die Seite zum ersten mal lade ohne das ein Request sien könnte, werden 6 Klassen umsonst includet, initialisiert und in deren Konstruktoren mind 3 IF-Abfragen bearbeitet. Sprich 18 IF-Abfragen umsonst.
Wie löst ihr sowas?

Diverse Probleme treten immer wieder auf, weswegen man dafür Lösungsmuster beschrieben hat. Das Pattern für dein Problem nennt sich Front Controller. Der nimmt als alleinige Instanz den Request entgegen, wertet signifikante Bestandteile davon aus und übergibt die Ausführung gezielt weiter. Die Ermittlung des Zieles kann man einem Routingmechanismus übergeben. Wenn sich das Ziel einfach ermitteln lässt, kann man das natürlich auch im Front Controller direkt erledigen. Der Front Controller muss nicht unbedingt eine Klasse sein. Er lässt sich auch als Funktion oder in einfachen Fällen als Geradeaus-Script in der index.php (oder wie auch immer man sie nennt) implementieren.

In modernen Frameworks, beispielsweise dem Zend Framework, wird ein Front Controller zusammen mit dem MVC-Pattern (das die Geschäftslogik implementiert) eingesetzt.

echo "$verabschiedung $name";