OOP: Aufteilung der Aufgaben innerhalb einer Anwendung

[Der-Dennis]

Hallo zusammen,

im Zuge der objektorientierten Programmierung und insbesondere des Model-View-Controller-Ansatzes habe ich mir nun schon öfter Gedanken darüber gemacht, wie man eine Anwendung aufbauen sollte.

Da ich zur Zeit fast ausschließlich mit PHP arbeite beziehe ich mich im folgenden auf eine PHP-Anwendung.

Die index.php ist die einzige ausführbare Datei, die direkt mittels HTTP aufgerufen werden kann. Dies wird mittels .htaccess-Direktiven ermöglicht.
In dieser Datei wird lediglich der Bibliotheks-Pfad in den PHP-Include-Path integriert, die Entwicklungsumgebung als Konstante definiert und ein neues Objekt (die Basis-Klasse der Anwendung, die sich in der Bibliothek befindet) erstellt. Dieser Klasse übergebe ich den Pfad zu einer Konfigurationsdatei.

Diese Basis-Klasse besteht im Wesentlichen aus drei Teilen:
1. Der Konstruktor: Hier werden alle für die Anwendung zwingend erforderlichen Aufgaben durchgeführt (wie z.B. das Auslesen der Config-Datei, Initialisierung des Autoloaders und Fehlerbehandlung, etc.)
2. Der Bootstrap-Prozess: Hier werden alle Aufgaben ausgeführt, die für die allgemeine Anwendung nicht zwingend sind, für die speziellere aber schon. Hierzu zählt beispielsweise die Authentifizierung und Autorisierung sowie das weitere Laden von Plugin-Klassen.
3. Der Start-Prozess: Hier wird die "eigentliche Anwendung" gestartet. Sprich: Der Front-Controller wird aufgerufen, welcher dann als oberste Instanz die weiteren Aufgaben an die anderen "normalen" Controller delegiert.

Meine Verzeichnisstruktur ist "stur" nach MVC ausgerichtet, es gibt also Module-Ordner, die dann Model-, View-, Controller-, Config-, Layout-Ordner oder ähnliches enthalten. Innerhalb dieser Ordner (Anmerkung: Genauso auch in der Bibliothek) steht jede Klasse in einer eigenen Datei.

Zusätlich zur Bibliothek und zur Anwendung gibt's bei mir noch einen Ordner "public", der die zuvor beschriebe index.php und - in Ordnern sortiert - statische Dateien wie Bilder, JavaScripts, CSS und so weiter enthält.

Soviel zu meiner aktuellen Vorgehensweise. Jetzt meine Fragen an Euch:

• Was haltet Ihr von OOP (speziell im PHP-Kontext)?
• Was haltet Ihr von MVC?
• Wie baut Ihr Eure Anwendungen auf?
• Was kommt bei Euch in den Initialisierungs-, was in den Bootstrap-Prozess?
• Arbeitet Ihr mit einem Front-Controller? Und wenn ja, wie verwendet Ihr ihn?
• ...

Über eine rege Diskussion würde ich mich sehr freuen!

Gruß, Dennis

[Sven Rautenberg]

Moin!

Soviel zu meiner aktuellen Vorgehensweise. Jetzt meine Fragen an Euch:

• Was haltet Ihr von OOP (speziell im PHP-Kontext)?
• Was haltet Ihr von MVC?
• Wie baut Ihr Eure Anwendungen auf?
• Was kommt bei Euch in den Initialisierungs-, was in den Bootstrap-Prozess?
• Arbeitet Ihr mit einem Front-Controller? Und wenn ja, wie verwendet Ihr ihn?
• ...

Über eine rege Diskussion würde ich mich sehr freuen!

Du dürftest wenig Widerspruch ernten - außer vielleicht von denen, die den Sinn von OOP noch nicht so wirklich verstanden haben. Schließlich entspricht deine Vorgehensweise durchaus guten Prinzipien, wie sie anerkannt als "best practice" in der Fachwelt gehandelt werden.

Allerdings: Ohne Frontcontroller - wie soll das gehen? Irgendwas muss an der Stelle doch immer die Kontrolle übernehmen.

- Sven Rautenberg

[Der-Dennis]

Hey Sven,

danke für Deine Antwort.

Du dürftest wenig Widerspruch ernten - außer vielleicht von denen, die den Sinn von OOP noch nicht so wirklich verstanden haben. Schließlich entspricht deine Vorgehensweise durchaus guten Prinzipien, wie sie anerkannt als "best practice" in der Fachwelt gehandelt werden.

Einerseits schön zu hören, auf der anderen Seite würden mich auch noch andere Sichtweisen interessieren. Man hört ja immer wieder, OOP sei zu langsam, PHP bietet auch so schon genug Funktionen, ...

Allerdings: Ohne Frontcontroller - wie soll das gehen? Irgendwas muss an der Stelle doch immer die Kontrolle übernehmen.

Da hast Du schon recht. Allerdings ist der Front-Controller bei mir eine obere Instanz: Er holt sich die Anfrage und ermittelt, welcher Controller und welche Aktion aufgerufen werden muss. Diese werden dann ausgeführt und geben die Kontrolle zurück zum Front-Controller, der dann die Daten sendet.
Einige Leute schwören aber darauf, dass es keinen Front-Controller in meinem obigen Sinne gibt. Vielmehr gibt es nur einen Router oder ähnliches, der den Controller und die Aktion aufruft und diese dann "auf sich allein gestellt sind".
Das halte ich zum Beispiel für wenig sinnvoll, da ich nur schwierig eventuell nötige Methoden aus anderen Controllern aufrufen kann und im Fehlerfall keine hörere Instanz darauf reagieren kann.

Gruß, Dennis

[Sven Rautenberg]

Moin!

Du dürftest wenig Widerspruch ernten - außer vielleicht von denen, die den Sinn von OOP noch nicht so wirklich verstanden haben. Schließlich entspricht deine Vorgehensweise durchaus guten Prinzipien, wie sie anerkannt als "best practice" in der Fachwelt gehandelt werden.

Einerseits schön zu hören, auf der anderen Seite würden mich auch noch andere Sichtweisen interessieren. Man hört ja immer wieder, OOP sei zu langsam, PHP bietet auch so schon genug Funktionen, ...

Wenn etwas langsam ist, dann ist das nicht OOP, sondern PHP an sich.

Und um über den Sinn oder Unsinn von OOP nachzudenken, sollte man sich mal irgendeine beliebige, aber naturgemäß etwas umfangreichere PHP-OOP-Anwendung nehmen und überlegen, was denn passieren würde, bzw. was das Resultat wäre, wenn man sämtliche Klassen wegließe und nur noch die zugrundeliegenden Funktionen und Eigenschaften hätte.

Nach meiner Ansicht würde das große Chaos ausbrechen, weil die Gruppierung von Funktionen in sinnvolle Sachzusammenhänge, die durch das Erstellen einer Klasse entsteht, vollkommen verloren geht. Man erhält also am Ende einen riesigen Pool von schlichten Funktionen, die alle gegenüber jeder anderen Funktion sichtbar sind. Es gibt keinerlei Möglichkeit, das einzuschränken, es gibt auch keine Möglichkeit, einer Funktion schon direkt im Parameter-Teil mitzuteilen, dass die ihr übergebenen Parameter gewissen Anforderungen zu erfüllen haben, also Objekte bestimmter Klassen sein müssen.

Was leistet OOP noch? Vererbung. Was spart man sich damit? Codeduplizierung. Eine Funktion kann nur schwerlich in den entscheidenden Punkten leicht modifiziert werden, ohne dass der Code der zugrundeliegenden Funktion nicht komplett kopiert werden müsste. Und wenn es doch ginge, würde man die Basisfunktion vermutlich in zwei oder drei Einzelteile aufbrechen müssen, um den relevanten Part dann durch eine Anpassung zu ersetzen. Insgesamt erhielte man ein sehr unübersichtliches Gebilde von diversen Funktionen.

Und wollte man diese Funktionen dann doch - durch ihre Namensgebung - sachlich gruppieren, würde man eben genau bei einer Vorstufe von objektorientierter Programmierung landen, d.h. man hätte alle Nachteile der rein funktionsorientierten Programmierung in PHP, ohne die Vorteile der objektorientierten Programmierung nutzen zu können.

Objektorientierte Programmierung dreht sich nicht um das "Auto-Objekt" mit dem eingebauten "Motor-Objekt", der "color"-Eigenschaft des Autos und den Variationen "Sportwagen" und "Lastwagen" dieses Objekts. Das sind alles Bildnisse, die dem Anfänger irgendwie ein Gefühl vermitteln sollen, dass er es hier mit Real-Welt-Objekten zu tun hat, indem reale Objekte verwendet werden, um das komplett virtuelle Objektorientierte zu vermitteln. Ich halte diese Metaphern eher für schädlich, denn in der realen OOP gibt es nur sehr selten Auto-Objekte mit Motor-Objekten, die tatsächlich echte Autos und Motoren darstellen.

Stattdessen sollte man OOP lieber begreifen und darstellen als einen Weg, seinen eigenen Code besser zu organisieren, effizienter zu nutzen, und leichter zu verstehen. Denn genau das ist das eigentliche Problem, welches von OOP besser gelöst wird, als von dem funktionsorientierten Ansatz.

Allerdings: Ohne Frontcontroller - wie soll das gehen? Irgendwas muss an der Stelle doch immer die Kontrolle übernehmen.

Da hast Du schon recht. Allerdings ist der Front-Controller bei mir eine obere Instanz: Er holt sich die Anfrage und ermittelt, welcher Controller und welche Aktion aufgerufen werden muss. Diese werden dann ausgeführt und geben die Kontrolle zurück zum Front-Controller, der dann die Daten sendet.
Einige Leute schwören aber darauf, dass es keinen Front-Controller in meinem obigen Sinne gibt. Vielmehr gibt es nur einen Router oder ähnliches, der den Controller und die Aktion aufruft und diese dann "auf sich allein gestellt sind".

Der Router gehört sicherlich mit in den Frontcontroller-Ablauf hinein. Bei deinem Frontcontroller ist das Routing halt statisch. Trotzdem muss es irgendeine Instanz geben, die letztendlich den eigentlichen Controller aufruft, nachdem der abzuarbeitende Request analysiert wurde.

Das genau ist für mich der Frontcontroller.

- Sven Rautenberg

[Der-Dennis]

Hey Sven,

sehr schön geschrieben und beschreibt die wesentlichen Punkte, wie auch ich sie sehe. Kann dem nichts wirklich hinzufügen und markiere den Post mal als "fachlich hilfreich".

Vielen Dank und gute Nacht,
Dennis

[fastix®]

Moin!

Objektorientierte Programmierung dreht sich nicht um das "Auto-Objekt" mit dem eingebauten "Motor-Objekt", der "color"-Eigenschaft des Autos und den Variationen "Sportwagen" und "Lastwagen" dieses Objekts. Das sind alles Bildnisse, die dem Anfänger irgendwie ein Gefühl vermitteln sollen, dass er es hier mit Real-Welt-Objekten zu tun hat,

Nein. Der Teilnehmer wird mit dem durchaus kindgerechten Beispiel (in welcher Herdt-Unterlage war es doch gleich?) in der Schulung oder im Seminar aus der realen Welt abgeholt ("Das kennen Sie doch!") und ihm wird vermittelt, was Objekte, Methoden, Eigenschaften und Werte überhaupt sind. Ihm wird gezeigt, was Vererbung ist

Fahrzeug -> Kraftfahrzeug -> Lastkraftwagen
                          -> PKW
                          -> Motorrad
         -> Fuhrwerk      -> Droschke
         -> Fahrrad

Dein Ansatz, dem Teilnehmer bei den von Dir genannten Problemen der funktionalen Programmierung abzuholen geht zwar auch, setzt aber mehr Hirnschmalz und vor allem Programmiererfahrungen jenseits des eigenen Einzelplatzes voraus, damit die Probleme bekannt sind(*).  Bei PHP-Schulungen besteht zu dem das Problem, dass man kaum so griffige Objekte wie z.B. Zellen (Excel-VBA) oder Formularelemente (VBA, VB u.v.a.m.) hat.

*) Ich habe vor Jahren mal in einer Excel-Schulung für "Fortgeschrittene" erklären wollen, was der Unterschied und das (nicht ganz kleine) resultierende Problem bei einer Optimierung mit den Mitteln der Algebra (Solver) und derjenigen mit den Mitteln der Analysis ist. Sogar ein gutes Beispiel vorbereitet, bei dem der Solver prompt zum falschen Ergebnis kommt und dann dargelegt, was das richtige Ergebnis ist und warum dies geschieht. Eine Teilnehmerin war eine Frau Doktor, der andere Teilnehmer einer der Geschäftsführer aus dem selben Unternehmen.

Das mache ich NIE wieder. (Oder: Was macht man eigentlich im Westen bis zum Abitur im Fach Mathematik? Abwählen?)

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[fastix®]

Moin!

Über eine rege Diskussion würde ich mich sehr freuen!

Klingt alles sehr löblich. Aber um einen einzelnen Nagel in ein Brett zu hauen nehme ich einen Hammer statt erst Strom zu legen, einen Kompressor zu beschaffen, diesen mit einer Nagelmaschine verbinden zu lassen, alles - es braucht noch einen Abstraktionslayer - dem TÜV vorzustellen und zertifizieren zu lassen und dann nach frühestens 114 Tagen (falls das Wetter den Auflagen des TÜV gerecht ist, sonst bedarf es weiterer 32 Tage allein für die Planung des nächsten Termins)

1. den Nagel unter Fanfarenklängen pneumatisch einschlagen zu lassen
2. eine 700-seitige Dokumentation an diesen Nagel zu hängen, in der steht wie ich es gemacht habe und wie der Vorgang wiederholt werden kann - was er auch muss, weil an dem Nagel ja schon genug hängt.

Der Theoretiker, der möglicherweise nach mir kommt, der mag dann zwar meckern: Aber ich bin mir sicher, der hat den zweiten Nagel auch schneller im Brett wenn er es so macht wie ich. Falls er sich dazu durch ringen kann.

Will sagen: Es kommt auf die Aufgabe an. Für ein "Hallo Welt, es ist jetzt 10:00 Uhr morgens!" werde ich jedenfalls den oben genannten Aufwand nicht treiben.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Der-Dennis]

Hallo fastix,

auch Dir vielen Dank für Deine Antwort und eine sehr schöne Analogie :-)

Will sagen: Es kommt auf die Aufgabe an. Für ein "Hallo Welt, es ist jetzt 10:00 Uhr morgens!" werde ich jedenfalls den oben genannten Aufwand nicht treiben.

Da hast Du schon vollkommen recht. Es geht schon um größere Projekte. Allerdinsg muss ich sagen, dass ich zuletzt auch bei kleineren Seiten dieses Prinzip genutzt habe, da ich mich sehr daran gewöhnt habe und die Funktionen hierzu ja schon vorhanden sind. Das sollte ich allerdings tatsächlich überdenken.

Gruß, Dennis

[fastix®]

Moin!

Das sollte ich allerdings tatsächlich überdenken.

"Guckst Du hier."

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Der-Dennis]

Hey fastix,

Das sollte ich allerdings tatsächlich überdenken.

"Guckst Du hier."

Der Vollständigkeit halber zitiere ich hier einen Teil aus Deinem oben genannten Post:

Das beschreibt dann auch gleich ein Problem der OOP: Performance. Ich führe sehr oft einen Haufen Prüfungen durch, derer es im tatsächlichen Kontext nicht bedarf, weil es "einfacher" (Wozu habe ich die Dokumentation der Klassen meines Kollegen gelesen) ist etwas wie

ipaddr $ip=&new ipaddr();

$ip->setIP($_SERVER['REMOTE_ADDR']);
print " Es handelt sich um eine IP-V" . $ip->typ . "-Adresse.";

>   
> zu notieren. Das ggf. schon die Methode setIP() einen Resolver aufruft um eine reverse Bestimmung des Hostnamens zu versuchen und das Ergebnis in der Klassenvariable hostname abzulegen (was auch mal mehrere Sekunden dauern kann) weiß ich nicht unbedingt...  
>   
> Damit sind wir bei einem weiteren Problem: Die Klasse (und damit das Objekt) ist für mich eine Black-Box, jedenfalls so lange ich nicht weiß, was diese wirklich macht  - ich weiß nur was diese machen soll, genau das steht ja in der (hoffentlich verfügbaren) Dokumentation.  
  
Hier stimme ich Dir natürlich zu. Nicht alles braucht eine eigene Funktion oder eigene Klasse, wenn man es auch effizient mit bereits implementierten Methoden oder etwas Logik durchführen kann.  
Das Zend Framework ist für mich so ein Beispiel, wo es Programmierer mit OOP "zu gut gemeint haben". Dabei erinnere ich mich insbesondere an die Klassen zur Anbindung an die Datenbank. Ich glaube nicht, dass es sinnvoll ist, eine Klasse zu erstellen, die lediglich den Namen einer Tabelle enthält.  
Also: OOP und Abstraktion nur da, wo es einen tatsächlichen Mehrwert bringt.  
  
Ich hoffe, das was in etwas das, was Du meintest.  
  
Gruß, Dennis

[Sven Rautenberg]

Moin!

Allerdinsg muss ich sagen, dass ich zuletzt auch bei kleineren Seiten dieses Prinzip genutzt habe, da ich mich sehr daran gewöhnt habe und die Funktionen hierzu ja schon vorhanden sind. Das sollte ich allerdings tatsächlich überdenken.

Aus welchen Gründen? Performance? Wohl eher nicht, bei kleinen Projekten ist das im Endeffekt eher egal. Relevant ist dagegen, dass man das Projekt schnell entwickelt hat. Und ggf. schnell erweitern kann.

Nun gut: Ich würde kein ausgewachsenes MVC-Framework für einen Formmailer einsetzen wollen. Die Formular-Validierungsklasse daraus hingegen schon. Und so kommt dann wahrscheinlich eins zum anderen, und die zahlreichen Annehmlichkeiten, die das Framework bietet, damit man sich nicht mehr mit Low-Level-Scheiß rumschlagen muss, werden nach und nach vermisst und nachgerüstet... :)

- Sven Rautenberg

[Der-Dennis]

Hey Sven!

Allerdings muss ich sagen, dass ich zuletzt auch bei kleineren Seiten dieses Prinzip genutzt habe, da ich mich sehr daran gewöhnt habe und die Funktionen hierzu ja schon vorhanden sind. Das sollte ich allerdings tatsächlich überdenken.

Aus welchen Gründen? Performance? Wohl eher nicht, bei kleinen Projekten ist das im Endeffekt eher egal.

Nicht aus Gründen der Performance, die, wie Du ja richtig sagst, bei kleineren Seiten eher irrelevant ist. Eher aus Gründen der Übersichtlichkeit und Wartbarkeit, wenn nicht ich oder einer meiner Kollegen sich mehr um die Seite kümmert, sondern ein weniger Web-affiner "Anwender".

Relevant ist dagegen, dass man das Projekt schnell entwickelt hat. Und ggf. schnell erweitern kann.

Das ist mein Grund für OOP und meine beschriebene Vorgehensweise mittels eigenem, kleinen Framework.

Nun gut: Ich würde kein ausgewachsenes MVC-Framework für einen Formmailer einsetzen wollen. Die Formular-Validierungsklasse daraus hingegen schon. Und so kommt dann wahrscheinlich eins zum anderen, und die zahlreichen Annehmlichkeiten, die das Framework bietet, damit man sich nicht mehr mit Low-Level-Scheiß rumschlagen muss, werden nach und nach vermisst und nachgerüstet... :)

Wie zuvor beschrieben, der Grund, warum ich so arbeite wie ich es zur Zeit mache :-)

Gruß, Dennis

[fastix®]

Moin!

Aus welchen Gründen? Performance? Wohl eher nicht, bei kleinen Projekten ist das im Endeffekt eher egal.

Nein! Gerade kleine Projekte laufen häufig auf shared hosts und da sind mitunter sehr viele andere Kunden mit drauf. Also sind diese Server relativ stark ausgelastet. Und genau deshalb ist es eben auch für die Antwortzeit der eigenen Skripte wichtig, das diese nicht zu viele Prozessortakte, Speicher und vor allem Dateisystemzugriffe "für nichts" verbraten.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Tom]

Hello Fastix,

Aus welchen Gründen? Performance? Wohl eher nicht, bei kleinen Projekten ist das im Endeffekt eher egal.

Nein! Gerade kleine Projekte laufen häufig auf shared hosts und da sind mitunter sehr viele andere Kunden mit drauf. Also sind diese Server relativ stark ausgelastet. Und genau deshalb ist es eben auch für die Antwortzeit der eigenen Skripte wichtig, das diese nicht zu viele Prozessortakte, Speicher und vor allem Dateisystemzugriffe "für nichts" verbraten.

*grins*
Da wissen die Programmierer von heute doch gar nicht mehr, was das eigentlich ist.

Aber genau das ist doch der Grund, warum ich OOP auf einem Interpretersystem für Nonsense halte.
Bei kleinen Projekten benötigt man es nicht und bei großen bringt es das Projekt (oft) zum Stehen. Ich muss mir da nur die diversen Shops im Internet angucken.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[fastix®]

Moin!

Aber genau das ist doch der Grund, warum ich OOP auf einem Interpretersystem für Nonsense halte.

Bitte nicht, das ist zu allgemein. Es gibt in vielen Skriptsprachen eine ganze Reihe von "natürlichen" Objekten haben (z.B. VBA und JS) und einige Objekte, die ich mir gerne - gut dokumentiert - für jede Programmiersprache wünschen würde.

Allein, wenn ich mir JS anschaue, da ist der Objektansatz viel ausgeprägter und er macht absolut Sinn, denn document, window selbst strings und arrays sind "native Objekte" und deren Eigenschaften will man ändern oder deren Methoden nutzen. Der ständige Wechsel zwischen der Verwendung nativer Objekte und Funktionen ist da schon sehr anstrengend und führt zu einen hohen Zuckerverbrauch. Wie oft habe ich in PHP schon $int=$array.count() notiert?

Mich ärgert z.B. immer wieder, dass es in PHP eine ganze Menge Funktionen nur für Arrays oder Strings gibt. Warum sind die nicht als Methoden angelegt? z.B. count(). Warum macht man so ein iniSet/iniGet- Geschwuchtel, statt $PHP kurzerhand als wunderbares Objekt zu behandeln in dem auch so Sachen wie ob_get_contents(), ob_end_flush(), ob_end_clean(), ob_implicit_flush(), ob_gzhandler(), ob_iconv_handler(),  mb_output_handler() und ob_tidyhandler() als Methode oder Eigenschaft angelegt sind?

Dito Datenbanken. Da gibt es "Quasi-Handler", "Result-Sets" (also: $DB=mysql_pc_connect(); $result=mysql_query($DB, $sql); ), etliche nur darauf bezogene Funktionen die nicht mal ein Argument brauchen (und so definitiv zur Schlampigkeit verführen)  - aber warum kein Objekt mit dem man etwa wie folgt umgehen kann oder, noch besser, muss:

$objDB = new Database;  
$objDB->type             = 'mysql';  
$objDB->host             = 'foo';  
$objDB->port             = 3306;  
$objDB->user             = 'bar';  
$objDB->passwd           = 'foobar';  
$objDB->shema            = 'barfoo';  
$objDB->PersitentConnect = true;         # false  
$objDB->connectType      = CONNECT_COMPRESSED; # CONNECT_SSL, CONNECT_COMPRESSED_SSL, RAW  
$objDB->connect();  
  
[code lang=php]$objResult=$objDB->execQuery($sql);

(Und ab hier hat man wieder das Theater mit den Arrays/Hashes.)

Wäre es an dem, dass PHP konsequenter wäre, dann würde wahrscheinlich vielen der objektorientierte Ansatz auch besser gefallen. Aber so ist PHP zumindest anfangs offensichtlich als prozedurale Sprache entwickelt worden - und daran, inklusive der resultierenden Macken, hält man gerne fest.

fastix

[dedlfix]

Hi!

Mich ärgert z.B. immer wieder, dass es in PHP eine ganze Menge Funktionen nur für Arrays oder Strings gibt. Warum sind die nicht als Methoden angelegt? z.B. count(). Warum macht man so ein iniSet/iniGet- Geschwuchtel, statt $PHP kurzerhand als wunderbares Objekt zu behandeln in dem auch so Sachen wie ob_get_contents(), ob_end_flush(), ob_end_clean(), ob_implicit_flush(), ob_gzhandler(), ob_iconv_handler(),  mb_output_handler() und ob_tidyhandler() als Methode oder Eigenschaft angelegt sind?

Würdest du das machen inklusive all der Konsequenzen, die eine Änderung zum jetzigen Zeitpunkt hat? PHP war nicht als OO-Sprache geplant. Das kam erst in Version 4 hinzu. Deinen Wunsch zu erfüllen würde entweder bedeuten, für nahezu alles eine zweite Schnittstelle zu erstellen und dann für alles eine zwei Schnittstelle zu pflegen. Oder aber man entfernt den herkömmlichen Weg zugunsten einer reinen OOP, was bedeutet, dass quasi alle Scripte neu geschreiben werden müssen, wenn du mit der neuen OOP-PHP-Version weiterarbeiten willst. Diejenigen, die heute schon OOP so weit wie möglich nutzen, müssen auch angefasst werden, weil auch sie garantiert an irgendwelchen Stellen Funktionsaufrufe drinhaben.

Dito Datenbanken. [...] aber warum kein Objekt mit dem man etwa wie folgt umgehen kann oder, noch besser, muss:

Das gibt es ja, aber als Option.

Wäre es an dem, dass PHP konsequenter wäre, dann würde wahrscheinlich vielen der objektorientierte Ansatz auch besser gefallen. Aber so ist PHP zumindest anfangs offensichtlich als prozedurale Sprache entwickelt worden - und daran, inklusive der resultierenden Macken, hält man gerne fest.

Wie gesagt, nicht nur offensichtlich sondern ausschließlich. Das Umschwenken auf reine OOP käme einem Neuanfang gleich.

Lo!

[fastix®]

Moin!

Würdest du das machen inklusive all der Konsequenzen, die eine Änderung zum jetzigen Zeitpunkt hat?

Auf gar keinen Fall! Dann "kotzen" weltweit eine oder zwei Millionen Leute, den Sturm will keiner erleben. Den Grund hast Du ja genannt.

Aber falls noch mal jemand den Rasmus machen will, dann soll er gleich korrekt loslegen :)

$objDB ...
Das gibt es ja, aber als Option.

Ich habe PDO schon gesehen.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Sven Rautenberg]

Moin!

Dito Datenbanken. Da gibt es "Quasi-Handler", "Result-Sets" (also: $DB=mysql_pc_connect(); $result=mysql_query($DB, $sql); ), etliche nur darauf bezogene Funktionen die nicht mal ein Argument brauchen (und so definitiv zur Schlampigkeit verführen)  - aber warum kein Objekt mit dem man etwa wie folgt umgehen kann oder, noch besser, muss:

Du suchst mysqli.

- Sven Rautenberg

[Tom]

Hello,

Zusätlich zur Bibliothek und zur Anwendung gibt's bei mir noch einen Ordner "public", der die zuvor beschriebe index.php und - in Ordnern sortiert - statische Dateien wie Bilder, JavaScripts, CSS und so weiter enthält.

"index.php": Also werden alle Dateien in diesem Verzeichnis vom Webserver daraufhimn geprüft, ob sie geparst werden sollen? Was haben dann z.B. Bilder in diesem Verzeichnis zu suchen? Wo lässt Du die übrigen Uploads der User?

• Was haltet Ihr von OOP (speziell im PHP-Kontext)?

Zum Üben ganz nett [...]

Aber bedenke, dass PHP bereits ein umfangreiches Runtime zur Verfügung stellt, dass im Falle von CGI bei jedem Request "bootstrapped" wird, im Falle von Apache-Modul-Version teilweise schon mit dem Apachen geladen wird. Bei Fast-CGI sieht es wohl auchz so aus, dass es residente Teile gibt? Man möge mich da bitte korrigieren.

Wenn Du jetzt noch einen OOP-Overhead draufsetzt, muss zumidest DER immer geladen werden, wenn der Request das verlangt. Das dauert dann...
Viel wichtiger als die horizontale Aufteilung in M-V-C erscheint mir daher die Vertikale Aufteilung dieser Programmteile in aufgabenbezogene Teilmodule, die durch Mechanismen, wie z.B. das Autoload von PHP tatsächlich nur dann geladen werden, wennn sie auch benötigt werden.

Die Einhaltung der Prinzipien von OOP und MVC bedeutet also, dass dein Metachart bei der Planung überlaufen wird. Tut es das nicht, machst Du 'was falsch ;-))

Ich halte es da eher wie Fastix: Für 'Hallo Welt' stellt das Runtime von PHP bereits alle Mechanismen zur Verfügung, die ich benötige und für noch viiiiel mehr!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der-Dennis]

Hallo Tom,

auch Dir herzlichen Dank für Deine Antwort.

"index.php": Also werden alle Dateien in diesem Verzeichnis vom Webserver daraufhimn geprüft, ob sie geparst werden sollen? Was haben dann z.B. Bilder in diesem Verzeichnis zu suchen? Wo lässt Du die übrigen Uploads der User?

Nein, da habe ich mich wohl falsch ausgedrückt. Die Struktur des Ordners public ist vom Prinzip her:
files/
  img/
  css/
  js/
  uploads/
  ...
index.php
.htaccess

In der .htaccess wird bestimmt, dass alle Aufrufe, die nicht an eine tatsächlich vorhandene Datei im Ordner files gerichtet sind, auf die index.php weitergeleitet werden. Die User-Uploads befinden sich auch in diesem Ordner.

• Was haltet Ihr von OOP (speziell im PHP-Kontext)?

Zum Üben ganz nett [...]

Was heißt "zum Üben ganz nett"? Verstehe ich leider nicht ganz.

Wenn Du jetzt noch einen OOP-Overhead draufsetzt, muss zumidest DER immer geladen werden, wenn der Request das verlangt. Das dauert dann...

Ja, aber durch geeignetes Caching kann man es zumindestens beschleunigen.

Viel wichtiger als die horizontale Aufteilung in M-V-C erscheint mir daher die Vertikale Aufteilung dieser Programmteile in aufgabenbezogene Teilmodule, die durch Mechanismen, wie z.B. das Autoload von PHP tatsächlich nur dann geladen werden, wennn sie auch benötigt werden.

Ich hoffe, dass ich das mache...

Ich halte es da eher wie Fastix: Für 'Hallo Welt' stellt das Runtime von PHP bereits alle Mechanismen zur Verfügung, die ich benötige und für noch viiiiel mehr!

Wie ich im Beitrag von fastix schon schrieb geht es um größere Anwendungen.

Fällt mir gerade noch ein: Meistens arbeiten mehrere Leute an einem Projekt. Auch das ist für mich ein Pro für OOP. Oder wie seht Ihr das?

Gruß, Dennis

[Tom]

Hello,

"index.php": Also werden alle Dateien in diesem Verzeichnis vom Webserver daraufhin geprüft, ob sie geparst werden sollen? Was haben dann z.B. Bilder in diesem Verzeichnis zu suchen? Wo lässt Du die übrigen Uploads der User?

Nein, da habe ich mich wohl falsch ausgedrückt. Die Struktur des Ordners public ist vom Prinzip her:
files/
  img/
  css/
  js/
  uploads/

Das bedeutet also, dass also zumindest Files, die in img oder uploads liegen, keinesfalls geparst werden? Wie sorgst Du dafür?

• Was haltet Ihr von OOP (speziell im PHP-Kontext)?

Zum Üben ganz nett [...]

Was heißt "zum Üben ganz nett"? Verstehe ich leider nicht ganz.

Ich halte OOP in einer nichtkompilierenden Scriptsprache für den Produktiveinsatz nach wie vor für fehl am Platze.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der-Dennis]

Hey Tom,

Das bedeutet also, dass also zumindest Files, die in img oder uploads liegen, keinesfalls geparst werden? Wie sorgst Du dafür?

Mit folgender .htaccess im Ordner public:

  
RewriteEngine On  
RewriteBase /  
  
RewriteCond %{REQUEST_FILENAME} -s [OR]  
RewriteCond %{REQUEST_FILENAME} -l [OR]  
RewriteCond %{REQUEST_FILENAME} -d  
RewriteRule ^.*$ - [NC,L]  
RewriteRule ^.*$ index.php [NC,L]  

, folgender .htaccess im Ordner files:

  
RewriteEngine off  
Options -Indexes  

und einer Subdomain namens static, die auf den Ordner files zeigt und über die alle Dateien aufgerufen werden.

Ich halte OOP in einer nichtkompilierenden Scriptsprache für den Produktiveinsatz nach wie vor für fehl am Platze.

Gut, das ist eine Meinung die man öfters hört. Ich denke aber, dass die Vorteile wie bessere Wiederverwendbarkeit den Nachteil Geschwindigkeit - der meiner Meinung nach durch gutes Caching in Grenzen gehalten werden kann - aufwiegen.

Gruß, Dennis

[Tom]

Hello Dennis,

Das bedeutet also, dass also zumindest Files, die in img oder uploads liegen, keinesfalls geparst werden? Wie sorgst Du dafür?

Mit folgender .htaccess im Ordner public:

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.$ - [NC,L]
RewriteRule ^.$ index.php [NC,L]

>   
> , folgender .htaccess im Ordner files:  
> ~~~perl
  

> RewriteEngine off  
> Options -Indexes  
> 

Das kann ich jetzt nicht wirklich verstehen.
Für mich heißt das dort oben:

Alle Requests nutzen die Ressourcen, die sie auch ohne RewriteCondition nutezen würden, sofern diese existieren und im Falle einer Datei auch einen Inhalt haben; alle Requests auf nicht existierende Ressourcen (und diejenigen auf Files ohne Inhalt) werden auf index.php umgeleitet.

Habe ich das jetzt richtig interpretiert?

Das würde aber nicht verhindern, dass ein File, der 'ich_bin_ein_bild.phps' heißt, und auf irgendwelche Art und Weise auch dort liegt, wo er vom Requestor erwartet wird, ggf. geparst wird.

Ich halte OOP in einer nichtkompilierenden Scriptsprache für den Produktiveinsatz nach wie vor für fehl am Platze.

Gut, das ist eine Meinung die man öfters hört. Ich denke aber, dass die Vorteile wie bessere Wiederverwendbarkeit den Nachteil Geschwindigkeit - der meiner Meinung nach durch gutes Caching in Grenzen gehalten werden kann - aufwiegen.

Ich weiß, das nützt dir auch nichts, dass mehrere Leute diese Meinung vertreten. Da PHP in der imperativen Form aber vermutlich nicht mehr so vervollständigt wird, dass man damit auch "vernünftig" programmieren kann, wird dir in deinem Fall nichts anderes übrig bleiben, als die PHP-OOP zu benutzen...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der-Dennis]

Hey Tom,

Das kann ich jetzt nicht wirklich verstehen.

scheinbar schon, denn

Alle Requests nutzen die Ressourcen, die sie auch ohne RewriteCondition nutezen würden, sofern diese existieren und im Falle einer Datei auch einen Inhalt haben; alle Requests auf nicht existierende Ressourcen (und diejenigen auf Files ohne Inhalt) werden auf index.php umgeleitet.

Habe ich das jetzt richtig interpretiert?

das ist meine Intention.

Das würde aber nicht verhindern, dass ein File, der 'ich_bin_ein_bild.phps' heißt, und auf irgendwelche Art und Weise auch dort liegt, wo er vom Requestor erwartet wird, ggf. geparst wird.

Du sagst es: "auf irgendeine Art und Weise". In dem Falle würde sie geparst werden. Es muss also verhindert werden, dass eine solche Datei überhaupt dort abgelegt werden kann, wo dies geschehen könnte.
Da die eigentliche Anwendung "oberhalb der Domain" liegt können nur Entwickler darauf zugreifen (und die achten hoffentlich darauf, dass nur "richtige" Dateien dort abgelegt werden).
Also ist die einzige Schwachstelle wohl der files-Ordner; hierbei insbesondere der Ordner mir User-Uploads.
Beim User-Upload wird natürlich je nach Kontext überprüft, was hochgeladen werden darf und was nicht. Wobei sich das zumeist auf einfache Überprüfungen wie Datei-Endung und/oder -Größe, etc., bezieht.

Aber aus genau solchen Gründen habe ich diesen Thread erstellt: Gibt es bessere Methoden, so etwas zu lösen?

Ich weiß, das nützt dir auch nichts, dass mehrere Leute diese Meinung vertreten. Da PHP in der imperativen Form aber vermutlich nicht mehr so vervollständigt wird, dass man damit auch "vernünftig" programmieren kann, wird dir in deinem Fall nichts anderes übrig bleiben, als die PHP-OOP zu benutzen...

Falls Du daruf hinaus möchtest, dass man wenn möglich eine andere Sprache verwenden sollte, stimme ich Dir zu. Mein Ausgangspost sollte sich aber darauf beziehen, ob OOP eine gute Lösung ist, wenn man - aus welchen Gründen auch immer - PHP verwenden muss.

Gruß, Dennis

[Tom]

Hello,

Das würde aber nicht verhindern, dass ein File, der 'ich_bin_ein_bild.phps' heißt, und auf irgendwelche Art und Weise auch dort liegt, wo er vom Requestor erwartet wird, ggf. geparst wird.

Du sagst es: "auf irgendeine Art und Weise". In dem Falle würde sie geparst werden. Es muss also verhindert werden, dass eine solche Datei überhaupt dort abgelegt werden kann, wo dies geschehen könnte.

Anders herum: Es muss von vornherein verhindert werden, dass Verzeichnisse (deren Dateien) geparst werden, in denen von Usern uploadbarer Content, Bilder, etc. landen können, sofern diese eben innerhalb der Document Root liegen.

Also ist die einzige Schwachstelle wohl der files-Ordner; hierbei insbesondere der Ordner mir User-Uploads.

Der ist meistens die Schwachstelle, ja.

Beim User-Upload wird natürlich je nach Kontext überprüft, was hochgeladen werden darf und was nicht. Wobei sich das zumeist auf einfache Überprüfungen wie Datei-Endung und/oder -Größe, etc., bezieht.

Aber bitte mit einer Positivliste, also nur erlaubte Endungen durchlassen.
Zusätzliche Maßnahmen, wie MIME-Type-Prüfung und getimagesize() auf dem Server sind nicht schädlich, aber alleine nicht ausreichend.

Falls Du daruf hinaus möchtest, dass man wenn möglich eine andere Sprache verwenden sollte, stimme ich Dir zu. Mein Ausgangspost sollte sich aber darauf beziehen, ob OOP eine gute Lösung ist, wenn man - aus welchen Gründen auch immer - PHP verwenden muss.

Nö, eine andere Sprache wollte ich jetzt nicht propagieren. PHP ist schon eine gute brauchbare Lösung. Sie ist leicht verständlich, wenn auch manchmal noch sehr chaotisch, was z.B. die Reihenfolge von Funktiomnsargumenten betrifft... Und die diversen Funktionen mit "Callbackfunktion" sind auch nicht unbedingt praktisch.

Aber man kann eben nicht alles haben.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der-Dennis]

Hey Tom,

Das würde aber nicht verhindern, dass ein File, der 'ich_bin_ein_bild.phps' heißt, und auf irgendwelche Art und Weise auch dort liegt, wo er vom Requestor erwartet wird, ggf. geparst wird.

Du sagst es: "auf irgendeine Art und Weise". In dem Falle würde sie geparst werden. Es muss also verhindert werden, dass eine solche Datei überhaupt dort abgelegt werden kann, wo dies geschehen könnte.

Anders herum: Es muss von vornherein verhindert werden, dass Verzeichnisse (deren Dateien) geparst werden, in denen von Usern uploadbarer Content, Bilder, etc. landen können, sofern diese eben innerhalb der Document Root liegen.

reden wir aneinander vorbei? Ich glaube nämlich, wir meinen das gleiche. Korrigier mich bitte, wenn ich da falsch liege und erkläre mir noch einmal, was Du meinst.

Aber bitte mit einer Positivliste, also nur erlaubte Endungen durchlassen.

Selbstverständlich!

Gruß, Dennis

[fastix®]

Moin!

Aber bitte mit einer Positivliste, also nur erlaubte Endungen durchlassen.
Selbstverständlich!

Äh. Bitte: Was interessiert (jenseits vom Apache/.htaccess) auf einer Linux/Unix-Kiste die Dateiendung? Die ist ja bei einem Upload durch einen böswilligen (oder noch schlimmer: unwissenden) User noch einfacher zu fälschen als der Mime-Type.

Oder hat die Software einen Ironie-Tag gekillt? Da bin ich aber ängstlich, dass die das jetzt auch mit Sonn-Tagen und womöglich sogar Sonn-Abenden macht.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[flowh]

Hallo fastix®.

Äh. Bitte: Was interessiert (jenseits vom Apache/.htaccess) auf einer Linux/Unix-Kiste die Dateiendung?

Eben für die Entscheidung, ob eine Datei als PHP-Datei ausgeführt wird oder nicht.

Servus,
Flo

[Tom]

Hello,

Hallo fastix®.

Äh. Bitte: Was interessiert (jenseits vom Apache/.htaccess) auf einer Linux/Unix-Kiste die Dateiendung?

Eben für die Entscheidung, ob eine Datei als PHP-Datei ausgeführt wird oder nicht.

oder als Perl-Datei
oder als JavaScript-Server-Datei
oder als JavaServlet
oder...

Daher sollten ganz bewusst nur Dateien mit festgelegten Endungen zugelassen werden zum Upload.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[fastix®]

Moin!

Daher sollten ganz bewusst nur Dateien mit festgelegten Endungen zugelassen werden zum Upload.

Und im Verzeichnis sollte zusätzlich jeder Zugriff auf andere Dateien verboten werden. Auch dazu werden die files- und files_match-Direktiven kostenlos mit dem alten Indianer geliefert

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Der-Dennis]

Hey fastix,

Aber bitte mit einer Positivliste, also nur erlaubte Endungen durchlassen.
Selbstverständlich!

Äh. Bitte: Was interessiert (jenseits vom Apache/.htaccess) auf einer Linux/Unix-Kiste die Dateiendung? Die ist ja bei einem Upload durch einen böswilligen (oder noch schlimmer: unwissenden) User noch einfacher zu fälschen als der Mime-Type.

unabhängig von den weiteren Antworten: Hier bezog ich mich auf die Positiv-Liste. Bei solchen Überprüfungen macht eine Negativ-Liste für mich keinen Sinn.

Gruß, Dennis

[Christian Seiler]

Hallo Tom,

Ich halte OOP in einer nichtkompilierenden Scriptsprache für den Produktiveinsatz nach wie vor für fehl am Platze.

Du hälst ja auch von OOP generell wenig. *stichel* ;-)

Viele Grüße,
Christian

[Tom]

Hello,

Ich halte OOP in einer nichtkompilierenden Scriptsprache für den Produktiveinsatz nach wie vor für fehl am Platze.

Du hälst ja auch von OOP generell wenig. *stichel* ;-)

Nee nee, das interpretierst Du falsch. Ich habe OOP doch erfunden ;-))

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Blaubart]

Tach.

Mist, jetzt habe ich mich verklickt und zuerst "fachlich hilfreich" erwischt. Schon blöd, daß die Bewertung dann auch direkt ohne Nachfrage (und Änderungsmöglichkeit) akzeptiert wird. ;)

Wenn Du jetzt noch einen OOP-Overhead draufsetzt, muss zumidest DER immer geladen werden, wenn der Request das verlangt. Das dauert dann...

Es ist ja nicht das erste Mal, daß Du solche und andere Weisheiten zum Thema OOP (und speziell OOP unter PHP) von Dir gibst. Kannst Du denn diese Aussagen auch mit für die Praxis relevanten Beispielen und Daten untermauern? Mir scheint eher, daß Du hier viele Vermutungen über ein Thema anstellst, über dessen Interna Du so gut wie nichts weißt.

Du mußt dieses Paradigma der OOP ja nicht gut finden; und nutzen schon gar nicht, wenn Du nicht willst. Aber argumentiere bitte nicht mit irgendwelchen Vermutungen im Gewand von Fakten.

[Tom]

Hello,

Du mußt dieses Paradigma der OOP ja nicht gut finden; und nutzen schon gar nicht, wenn Du nicht willst. Aber argumentiere bitte nicht mit irgendwelchen Vermutungen im Gewand von Fakten.

Du bist also der Meinung, dass OoP im Interpreterumfeld (nicht kompilierend) also _keinen_ Overhead darstellt? Wie soll das gehen?

Es liegt der OoP in PHP dasselbe Runtimesystem zugrunde, wie bei der Imperativen Programmierung. Die Klassendefinitionen stellen inclusive ihrer Abhängigkeiten zueinander eine zusätzliche Belastung dar.

Und um das nochmals klarzustellen: Ich bin nicht grundsätzlich gegen OoP. Die OoP war schon zu Assemblerzeiten benutzbar und hat dem Programmierer (teilweise) die Arbeit erleichtert. Aber man erkannte damals noch sehr gut, dass sie erheblich mehr Speicherplatz und auch mehr Taktzyklen schluckt.

Willst Du das auch anzweifeln?

Wenn man nun die Klassendefinitonen erst noch durch den Interpreter jagen muss, kostet das nochmals Rechenzeit.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Blaubart]

Tach.

Du bist also der Meinung, dass OoP im Interpreterumfeld (nicht kompilierend) also _keinen_ Overhead darstellt?

Nein, bin ich nicht. Ich bitte Dich lediglich darum, Dein schwammiges "das dauert dann..." z. B. mit Beipielen oder Meßdaten aus der Praxis zu quantifizieren. Entweder ist der Overhead durch OOP in Produktivsystemen relevant (dann wäre Dein Einwand gerechtfertigt und hilfreich) im Vergleich zum Rest oder nicht. Du implizierst durch Deine Aussage ersteres.

Wenn man nun die Klassendefinitonen erst noch durch den Interpreter jagen muss, kostet das nochmals Rechenzeit.

Du bekommst keine zusätzliche Funktionalität zum Nulltarif. Nicht bei PHP und auch sonst nicht. Das ist auch überhaupt nicht der Punkt. Die Frage ist, in welchem Verhältnis der zusätzliche Aufwand zum bisherigen Aufwand und zum Nutzen steht. Und auch die absoluten Zahlen sind interessant: Wenn bspw. die Verabeitung eines Datensatzes mit Methode A 5 ms dauert und mit Methode B dreimal so lange, die anschließende Übertragung des Ergebnisses aber mit 100 ms zu Buche schlägt und der Benutzer obendrein erst ab Wartezeiten über 500 ms ungeduldig wird, ist der Overhead einfach irrelevant und auch tragbar, wenn aus Methode B bspw. ein verständlicheres, besser wartbares und erweiterbares Programm resultiert.

Die OoP war schon zu Assemblerzeiten …

(Überrascht mich nicht, daß das jetzt wieder kommt.)

… benutzbar und hat dem Programmierer (teilweise) die Arbeit erleichtert. Aber man erkannte damals noch sehr gut, dass sie erheblich mehr Speicherplatz und auch mehr Taktzyklen schluckt.

Ja. Na und? Siehe oben. Möchtest Du lieber Deine Webanwendungen in Assembler schreiben, um auf jeder Plattform das Optimum² an Performance und Speichernutzung herauszuholen¹? Diese Herangehensweise hat nach wie vor ihre Berechtigung in einigen Bereichen. Die üblichen Webanwendungen, die z. B. in PHP geschrieben werden, gehören mit Sicherheit nicht dazu. Wieder eine Frage des Verhältnisses (s. o.). Bei solchen Anwendungen sind eine vernünftige Struktur, durchdachte Algorithmen³ und die Wartbarkeit ein wesentliches Kriterium. Und wenn jemand dies durch den Einsatz von OOP in PHP verbessert sieht, solltest Du schon mehr als ein "das dauert dann..." ins Feld führen, um den zusätzlichen Overhead als Gegenargument geltend zu machen.

--

¹ Abgesehen mal davon, daß allein das Schreiben in Assembler überhaupt keine bessere Performance garantiert als mit compiler-/interpretergeneriertem Code aus einer Hochsprache mit tausendundeins Abstraktionebenen und Konstrukten, die dem Menschen beim Verstehen und Schreiben des Codes unterstützen sollen.

² Zur Optimierungsthematik, die jedes Mal in Deinen Beiträgen zu diesem Thema mitschwingt, sage ich nur folgendes: Optimiere nicht aus Prinzip an irgendetwas herum, sondern nur dann, wenn es wirklich Performanceprobleme gibt.

³ häufig viel effektiver als Instruktionengeschubse und das Feilschen um jeden Prozessortakt und jedes Byte auf Assemblerebene

[dedlfix]

Hi!

Die index.php ist die einzige ausführbare Datei, die direkt mittels HTTP aufgerufen werden kann. Dies wird mittels .htaccess-Direktiven ermöglicht.
In dieser Datei wird lediglich der Bibliotheks-Pfad in den PHP-Include-Path integriert,

Geht das nicht bereits in der Grundkonfiguration von PHP oder in einer Per-Verzeichnis-Konfiguration (.htaccess bei mod_php, .user.ini für CGI ab PHP 5.3.0)?

die Entwicklungsumgebung als Konstante definiert

Was willst du damit bezwecken? Soll das ein abfragbares Flag sein, ob Debug-Code ausgeführt werden soll, wenn du gerade am Entwickeln bist, nicht jedoch im Produktivsystem?

Diese Basis-Klasse besteht im Wesentlichen aus drei Teilen:

1. Der Konstruktor: Hier werden alle für die Anwendung zwingend erforderlichen Aufgaben durchgeführt (wie z.B. das Auslesen der Config-Datei, Initialisierung des Autoloaders und Fehlerbehandlung, etc.)

Durchgeführt oder angestoßen? Monster-Methode oder Aufrufe spezialisierter Methoden?

2. Der Bootstrap-Prozess: Hier werden alle Aufgaben ausgeführt, die für die allgemeine Anwendung nicht zwingend sind, für die speziellere aber schon. Hierzu zählt beispielsweise die Authentifizierung und Autorisierung sowie das weitere Laden von Plugin-Klassen.

Woher weißt du denn zu dem Zeitpunkt schon, ob eine Authentifizierung überhaupt notwendig ist und wenn ja, wofür man autorisiert sein muss?

3. Der Start-Prozess: Hier wird die "eigentliche Anwendung" gestartet. Sprich: Der Front-Controller wird aufgerufen, welcher dann als oberste Instanz die weiteren Aufgaben an die anderen "normalen" Controller delegiert.

Und nachdem der Action-Controller tätig, was passiert dann? Führt der Action-Controller auch die View aus oder gibt er eine fertig präparierte View zurück, die der Front-Controller dann ausführt? Letzeres ist zum Beispiel für TDD sinnvoll. Ein Action-Controller kann besser getestet werden, wenn er ein View-Objekt mit einzeln prüfbaren Daten zurückgibt statt einer fertigen Textwurst oder einer bereits erfolgten Ausgabe.

Meine Verzeichnisstruktur ist "stur" nach MVC ausgerichtet, es gibt also Module-Ordner, die dann Model-, View-, Controller-, Config-, Layout-Ordner oder ähnliches enthalten. Innerhalb dieser Ordner (Anmerkung: Genauso auch in der Bibliothek) steht jede Klasse in einer eigenen Datei.

Was am Ende sinnvoll und praktisch ist und was nicht, wirst du im Laufe der Zeit als Erfahrung sammeln. Auch - und das ist der entscheidende Punkt, um deine gesamte Absicht bewerten zu können - kommt es auf das konkrete Ziel an. Willst du nur mal üben oder ein konkretes (wichtiges) Projekt realisieren?

Zusätlich zur Bibliothek und zur Anwendung gibt's bei mir noch einen Ordner "public", der die zuvor beschriebe index.php und - in Ordnern sortiert - statische Dateien wie Bilder, JavaScripts, CSS und so weiter enthält.

Was ist das für eine Bibliothek? Eine selbst erstellte oder eine von der Stange - welche?

Soviel zu meiner aktuellen Vorgehensweise. Jetzt meine Fragen an Euch:

• Was haltet Ihr von OOP (speziell im PHP-Kontext)?

Kommt auf die Aufgabenstellung und das abzuschätzende Verhältnis zwischen Aufwand und Nutzen an.

• Was haltet Ihr von MVC?
• Wie baut Ihr Eure Anwendungen auf?

Kommt auf Art und Umfang der Anwendung an. Wenn ich ein ASP.NET-Projekt erstelle, führt quasi kein Weg an ASP.NET MVC vorbei, wenn ich nicht gerade den an die Desktop-Programmierung angelehnten herkömmlichen ASP.NET-Ansatz mit fertigen Komponenten mit teilweise schrecklichem HTML-Code als Ergebnis sowie ereignisgesteuerter Programmierung gehen will.

Wenn das Ziel eine Website in der Größenordnung für Kleinunternehmer oder kleine Hobbyunternehmungen ist - ein paar Seiten und etwas Schnickschnack - also bei Projekten, wo man die Übersicht über die verwendeten Variablen und dergleichen noch im Kopf behalten und auch nach einer Pause schnell wiedererlangen kann - reicht mir oft die Aufteilung nach EVA. Da ist die index.php selbst das Gegenstück zum Front-Controller, der schon selbständig 0815-Seiten erstellen kann. Und wenn eine Aktion was besonderes benötigt, kommt eine Funktion hinzu, die quasi die Aufgabe der Action im Action-Controllers übernimmt.

Damit wäre dann zwischen den Zeilen auch die erste Frage beantwortet. MVC ist eins von vielen Lösungsmustern. Solche Patterns beschreiben den Weg zum Ziel und nicht konkret, wie die Implementierung aussehen soll. Das MVC-Pattern kann man also auch anwenden, ohne dass man mehr oder weniger buchstabengetreu Model-Klassen, View-Klassen und Controller-Klassen erstellt. Und man kann von diesem Prinzip abweichen, wenn man es für sinnvoll hält.

Beispielsweise kann man die ganze Angelegenheit um View-Models ergänzen. Mitunter will man in der View mehr Daten darstellen, als das eigentliche Model liefert, oder man muss mehrere Models befragen, um alle Daten zu bekommen. Dann kann man sich ein View-Model erstellen, in das der Controller alle benötigten Daten vereint. Oder aber, das Model ist zu umfangreich im Hinblick auf die Daten, die es liefern kann oder den Funktionsumfang, den man auch noch aus der View heraus missbrauchen könnte, wenn man selbiger eine Referenz aufs Model übergibt. Dann kopiert man nur die benötigten Daten ins View-Model, um der View oder dem View-Ersteller nicht mehr Angriffsfläche als nötig zu bieten.

• Was kommt bei Euch in den Initialisierungs-, was in den Bootstrap-Prozess?

Alles notwendige, aber möglichst nichts überflüssiges. Konkreter kann ich das ohne Kenntnis des Ziels nicht beantworten.

• Arbeitet Ihr mit einem Front-Controller? Und wenn ja, wie verwendet Ihr ihn?

Die Frage hört sich so an, als ob du dir selbst das MVC-Framework stricken willst. Du musst dir überlegen, welche Aufgaben du welcher Komponente geben willst, wie aufwendig die jeweiligen Teilaufgaben sind und ob man die nicht besser in noch weiter spezialisierte Konstrukte bringt (reicht eine Methode oder wäre eine eigene Klasse besser?).

Der Front-Controller muss ja auch die Zuordnung zwischen URL und der Action im Action-Controller herstellen. Hast du in deiner URL ein starres Prinzip, dann kann der Front-Controller daraus recht einfach das Ziel ableiten. Oder kann sie beliebig viele Elemente haben, dann wäre ein Router, der einen Satz Regeln auf Treffer prüft, eine Lösung. Oder man macht es universell verwendbar, indem man einen einfachen Router für den einen Fall und einen komplexeren für den anderen Fall einbinden kann.

Lo!

[Der-Dennis]

Hey dedlfix,

auch Dir danke für Deine Antwort.

Die index.php ist die einzige ausführbare Datei, die direkt mittels HTTP aufgerufen werden kann. Dies wird mittels .htaccess-Direktiven ermöglicht.
In dieser Datei wird lediglich der Bibliotheks-Pfad in den PHP-Include-Path integriert,

Geht das nicht bereits in der Grundkonfiguration von PHP oder in einer Per-Verzeichnis-Konfiguration (.htaccess bei mod_php, .user.ini für CGI ab PHP 5.3.0)?

Ich habe ehrlich gesagt keine Ahnung. Werd gleich mal danach suchen.

die Entwicklungsumgebung als Konstante definiert

Was willst du damit bezwecken? Soll das ein abfragbares Flag sein, ob Debug-Code ausgeführt werden soll, wenn du gerade am Entwickeln bist, nicht jedoch im Produktivsystem?

Genauso ist es. Abhängig von der Umgebung werden unterschiedliche Konfigurationen verwendet.

Diese Basis-Klasse besteht im Wesentlichen aus drei Teilen:

1. Der Konstruktor: Hier werden alle für die Anwendung zwingend erforderlichen Aufgaben durchgeführt (wie z.B. das Auslesen der Config-Datei, Initialisierung des Autoloaders und Fehlerbehandlung, etc.)

Durchgeführt oder angestoßen? Monster-Methode oder Aufrufe spezialisierter Methoden?

Angestoßen trifft es wohl besser. Im Konstruktor befinden sich eigentlich nur weitere Methodenaufrufe im Stil von

  
public function __construct($configPath = '')  
{  
  $this->initConfig();  
  $this->initErrorHandling();  
  $this->initAutoloader();  
  // usw.  
}  

Also keine Monster-Methode.

2. Der Bootstrap-Prozess: Hier werden alle Aufgaben ausgeführt, die für die allgemeine Anwendung nicht zwingend sind, für die speziellere aber schon. Hierzu zählt beispielsweise die Authentifizierung und Autorisierung sowie das weitere Laden von Plugin-Klassen.

Woher weißt du denn zu dem Zeitpunkt schon, ob eine Authentifizierung überhaupt notwendig ist und wenn ja, wofür man autorisiert sein muss?

Auch hier sollte ich besser "angestoßen" bzw. "geladen" oder "initialisiert" verwenden. Im Front-Controller wird dies erst tatsächlich ausgeführt.

Und nachdem der Action-Controller tätig, was passiert dann? Führt der Action-Controller auch die View aus oder gibt er eine fertig präparierte View zurück, die der Front-Controller dann ausführt? Letzeres ist zum Beispiel für TDD sinnvoll. Ein Action-Controller kann besser getestet werden, wenn er ein View-Objekt mit einzeln prüfbaren Daten zurückgibt statt einer fertigen Textwurst oder einer bereits erfolgten Ausgabe.

Es gibt sozusagen eine "globale View" und eine "spezielle View". Ein Controller bzw. dessen Aktionen dürfen nur Werte in Ihre eigene, spezielle View speichern. Die "globale View" kann also aus mehreren dieser speziellen bestehen. Der Front-Controller gibt dann letztendlich das "Zeichen", dass die View zusammengesetzt und ausgegeben wird.

Was am Ende sinnvoll und praktisch ist und was nicht, wirst du im Laufe der Zeit als Erfahrung sammeln. Auch - und das ist der entscheidende Punkt, um deine gesamte Absicht bewerten zu können - kommt es auf das konkrete Ziel an. Willst du nur mal üben oder ein konkretes (wichtiges) Projekt realisieren?

Es geht um nichts konkretes. Wie gesagt, ich arbeite schon länger mit OOP und MVC und möchte einfach auf dem Laufenden bleiben bzw. andere Meinungen hören. Man lernt ja nie aus - besonders nicht in diesem Forum :-)

Was ist das für eine Bibliothek? Eine selbst erstellte oder eine von der Stange - welche?

Eine selbsterstellte, wobei sie sich auch bereits fertiger Klassen und Methoden aus beispielsweise dem Zend Framework bedient. Da kommt alles rein, was ich für sinnvoll halte oder sich für mich etabliert hat. Und wenn ich ein neues Proekt starte, kommt erstmal nur die "Standard-Anwendung" in den Bibliotheks-Ordner und anschließend dann - wenn benötigt - weitere Komponenten.

Vielen Dank auch für Deine weitere Ausführung. Da kann man ja nicht mehr viel zu sagen.

Gruß, Dennis

[Der-Dennis]

Die index.php ist die einzige ausführbare Datei, die direkt mittels HTTP aufgerufen werden kann. Dies wird mittels .htaccess-Direktiven ermöglicht.
In dieser Datei wird lediglich der Bibliotheks-Pfad in den PHP-Include-Path integriert,

Geht das nicht bereits in der Grundkonfiguration von PHP oder in einer Per-Verzeichnis-Konfiguration (.htaccess bei mod_php, .user.ini für CGI ab PHP 5.3.0)?

Ich habe ehrlich gesagt keine Ahnung. Werd gleich mal danach suchen.

Hierzu kann ich nichts finden. Entweder suche ich falsch oder so etwas ist nicht möglich. Weiß jemand Rat?

Gruß, Dennis

[fastix®]

Moin!

In dieser Datei wird lediglich der Bibliotheks-Pfad in den PHP-Include-Path integriert,
Geht das nicht bereits in der Grundkonfiguration von PHP oder in einer Per-Verzeichnis-Konfiguration (.htaccess bei mod_php, .user.ini für CGI ab PHP 5.3.0)?

...

Hierzu kann ich nichts finden. Entweder suche ich falsch oder so etwas ist nicht möglich. Weiß jemand Rat?

Ich fand es auf Anhieb.

Das geht, wenn erlaubt auch in der .htaccess. Das das Beispiel auch noch die Modulation des  PHP-Include-Path zeigt ist allerdings purer Zufall. Man kann damit mehr beeinflussen.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Der-Dennis]

Hey fastix,

da habe ich wohl in eine völlig falsche Richtung gesucht. Aber zu obigem: Welchen Vorteil habe ich hierdurch? Bewirken wird es ja wohl das gleiche.

Gruß, Dennis

[dedlfix]

Hi!

Aber zu obigem: Welchen Vorteil habe ich hierdurch? Bewirken wird es ja wohl das gleiche.

Konfigurationswerte in die Konfigurationsdateien einzufügen hat den (geringen) Vorteil, dass man sich einen Funktionsaufruf im Script spart. Es ist vielleicht mehr eine Philosophiefrage. Wo legt man Konfigurationswerte ab beziehungsweise stellt sie ein, die nicht unmittelbar das Geschehen im Programm beeinflussen. Suchpfade für Bibliotheksdateien, Angaben zum PHP-Fehlerreporting und sowas würde ich dazu zählen.

Lo!

[Der-Dennis]

Hey,

Konfigurationswerte in die Konfigurationsdateien einzufügen hat den (geringen) Vorteil, dass man sich einen Funktionsaufruf im Script spart.

Du sagst es ja schon, das ist - wenn überhaupt - ein sehr, sehr geringer Vorteil. Ich dachte da kommt mehr von Dir :-)

Es ist vielleicht mehr eine Philosophiefrage. Wo legt man Konfigurationswerte ab beziehungsweise stellt sie ein, die nicht unmittelbar das Geschehen im Programm beeinflussen. Suchpfade für Bibliotheksdateien, Angaben zum PHP-Fehlerreporting und sowas würde ich dazu zählen.

Das wird's dann wohl sein; also eine Philosophie-Frage. Ich setze die Einstellungen auf jeden Fall lieber im Skript, da ich sie dann zur Laufzeit dynamisch ändern kann.

Gruß, Dennis

[fastix®]

Moin!

Das wird's dann wohl sein; also eine Philosophie-Frage. Ich setze die Einstellungen auf jeden Fall lieber im Skript, da ich sie dann zur Laufzeit dynamisch ändern kann.

Nicht Pholosphie, sondern Praxis: Wenn Entwicklungssystem und Produktivsystem sich in Einstellungen unterscheiden, dann ist die Idee, einige Sachen wie error_reporting, Datenbankzugangsdaten(*) oder Pfade (also letztendlich die Einstellungen, die vom aktuellen Server abhängig sind) in der .htaccess mit unterzubringen, durchaus charmant. Man kann es nämlich recht einfach vermeiden diese .htaccess als Datei mit auf den Server zu übertragen. In einer "config.php" könnte sonst ein zu häufiger Änderungsbedarf entstehen.

*) Sammlung aus der php.ini für mysql und mysqli

mysql.allow_persistent = Off  
mysql.max_persistent = -1  
mysql.max_links = -1  
mysql.default_port =  
mysql.default_socket =  
mysql.default_host =  
mysql.default_user =  
mysql.default_password =  
mysql.connect_timeout = 60  
mysql.trace_mode = Off  
  
mysqli.max_links = -1  
mysqli.default_port = 3306  
mysqli.default_socket =  
mysqli.default_host =  
mysqli.default_user =  
mysqli.default_pw =  
mysqli.reconnect = Off

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Der-Dennis]

Hey fastix,

Nicht Pholosphie, sondern Praxis: Wenn Entwicklungssystem und Produktivsystem sich in Einstellungen unterscheiden, dann ist die Idee, einige Sachen wie error_reporting, Datenbankzugangsdaten(*) oder Pfade (also letztendlich die Einstellungen, die vom aktuellen Server abhängig sind) in der .htaccess mit unterzubringen, durchaus charmant. Man kann es nämlich recht einfach vermeiden diese .htaccess als Datei mit auf den Server zu übertragen. In einer "config.php" könnte sonst ein zu häufiger Änderungsbedarf entstehen.

das ist natürlich auch eine Möglichkeit. Um das häufige Ändern zu vermeiden definiere ich am Anfang der index.php eine Konstante die die Entwicklungsumgebung beschreibt. Abhängig hiervon werden unterschiedliche Einstellungen verwendet.
Gibt es da einen wesentlichen Unterschied zu Deiner beschriebenen Vorgehensweise? Oder besser: Bringt meine Vorgehensweise irgendwelche Nachteile mit sich?

Gruß, Dennis

[fastix®]

Moin!

das ist natürlich auch eine Möglichkeit. Um das häufige Ändern zu vermeiden definiere ich am Anfang der index.php eine Konstante die die Entwicklungsumgebung beschreibt. Abhängig hiervon werden unterschiedliche Einstellungen verwendet.
Gibt es da einen wesentlichen Unterschied zu Deiner beschriebenen Vorgehensweise? Oder besser: Bringt meine Vorgehensweise irgendwelche Nachteile mit sich?

Ja. Ich muss nicht mit einer "monster-index.php" arbeiten. Ich verwende das gleiche Mainscript immer nur für eine Art der Aufgabe (oder inhaltlichen Typ der Seite), includes enthalten Funktions-Bibliotheken, Klassen-Bibliotheken oder  wiederkehrende Aufgaben (z.B. Auth-Prüfungen) Ich mag Monsterskripte nicht und ich halte das für eine vollkommen unnötige Komplikation und damit Fehlerquelle. Habe ich aber mehrere Skripte, dann steigt bei Deiner Vorgehensweise (setzen im Skript) der Änderungsbedarf.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Der-Dennis]

Hey!

Ja. Ich muss nicht mit einer "monster-index.php" arbeiten.

Das sehe ich genauso.

Ich verwende das gleiche Mainscript immer nur für eine Art der Aufgabe (oder inhaltlichen Typ der Seite),

Hier verstehe ich nicht ganz, was Du mir sagen willst.

includes enthalten Funktions-Bibliotheken, Klassen-Bibliotheken oder  wiederkehrende Aufgaben (z.B. Auth-Prüfungen)

Auch bei mir laden dies Includes.

Ich mag Monsterskripte nicht und ich halte das für eine vollkommen unnötige Komplikation und damit Fehlerquelle.

Die mag ich wie oben gesagt auch nicht.

Habe ich aber mehrere Skripte, dann steigt bei Deiner Vorgehensweise (setzen im Skript) der Änderungsbedarf.

Warum?

Meine index.php macht im Grunde folgendes:

• Definiere eine Konstante mit der zu verwendenden Entwicklungsumgebung -> dies ist die einzige Änderung, die ich vornehmen muss (wenn ich beispielsweise zwischen Produktions- und Entwicklungsumgebung umschalte)

• Füge den Pfad zur Bibliothek hinzu, in der sich die (Haupt-)Anwendung befindet

• Rufe die Anwendung auf (erstelle ein neues Anwendungsobjekt) und gebe diesem die Umgebung sowie einen Pfad zu einer Konfigurationsdatei mit.

Für mich ist das keine monster-index.php!?

Gruß, Dennis

[fastix®]

Moin!

Für mich ist das keine monster-index.php!?

1)

Sagen wir es mal so: Ich will, zwecks Vermeidung von Kopfscherzen, keine if-then-else oder case-Wüsten editieren. Wenn ich das anders geregelt bekomme, dann mache ich das auch anders.

2)

Hat ein Skript mehr als 10k, dann ist es eine sehr große Bibliothek mit sehr vielen Funktionen oder Klassen (die ja für sich immer schöne abgeschlossene Einheiten sind) oder es erledigt wirklich umfangreiche und einzigartige Aufgaben. Viele der aufgabenorientierten Skripte (die also keine Bibliotheken sind) haben bis zu 2k und senden bestenfalls header. Das ist schön übersichtlich - besonders wenn man sprechende Dateinamen verwendet.

3)

Ich verwende das gleiche Mainscript immer nur für eine Art der Aufgabe (oder inhaltlichen Typ der Seite),
Hier verstehe ich nicht ganz, was Du mir sagen willst.

Alles Seiten mit einer grundsätzlich eigenen Logik bekommen von mir eine eigenes Skript-Datei und die heißt nicht index.php und das wird auch nicht von einer index.php includiert. Die haben also auch eine eigene _echte_ URL. Das spart die Mühen und die Kopfschmerzen hinsichtlich Punkt 1. Eine grundsätzlich eigene Logik (natürlich unter Verwendung der Bibliotheken) haben bei mir alle Seiten die irgendwie mit Authentifizierung (für Backoffice/Administration) zu tun haben, auf Grund von Datenbankabfragen aufgebaut werden (große Tabellen) oder die umfangreiche Formulare erzeugen oder deren Daten verarbeiten.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Der-Dennis]

Hi fastix,

Für mich ist das keine monster-index.php!?

1)

Sagen wir es mal so: Ich will, zwecks Vermeidung von Kopfscherzen, keine if-then-else oder case-Wüsten editieren. Wenn ich das anders geregelt bekomme, dann mache ich das auch anders.

auch hier gebe ich Dir recht. Aber das, was ich vorher beschrieben habe, sagt doch gar nicht, dass ich "if-then-else oder case-Wüsten" benutze!? Eher im Gegenteil.

2)

Hat ein Skript mehr als 10k, dann ist es eine sehr große Bibliothek mit sehr vielen Funktionen oder Klassen (die ja für sich immer schöne abgeschlossene Einheiten sind) oder es erledigt wirklich umfangreiche und einzigartige Aufgaben. Viele der aufgabenorientierten Skripte (die also keine Bibliotheken sind) haben bis zu 2k und senden bestenfalls header. Das ist schön übersichtlich - besonders wenn man sprechende Dateinamen verwendet.

Hier kann ich Dir leider wieder nicht ganz folgen. Was möchtest Du mir hiermit sagen (nicht böse gemeint; aber trotz einigem Nachdenken komme ich nicht dahinter)?

3)

Ich verwende das gleiche Mainscript immer nur für eine Art der Aufgabe (oder inhaltlichen Typ der Seite),
Hier verstehe ich nicht ganz, was Du mir sagen willst.

Alles Seiten mit einer grundsätzlich eigenen Logik bekommen von mir eine eigenes Skript-Datei und die heißt nicht index.php und das wird auch nicht von einer index.php includiert. Die haben also auch eine eigene _echte_ URL. Das spart die Mühen und die Kopfschmerzen hinsichtlich Punkt 1. Eine grundsätzlich eigene Logik (natürlich unter Verwendung der Bibliotheken) haben bei mir alle Seiten die irgendwie mit Authentifizierung (für Backoffice/Administration) zu tun haben, auf Grund von Datenbankabfragen aufgebaut werden (große Tabellen) oder die umfangreiche Formulare erzeugen oder deren Daten verarbeiten.

Auch dies fällt mir schwer zu verstehen (wahrscheinlich da ich Punkt 1 und 2 schon nicht richtig folgen konnte). Kannst Du mir das bitte noch einmal erklären?
Denn:

• ob eine Datei index.php oder was-weiss-ich.php heißt, ist doch vordergründig egal?
• die - zumindest von mir beschriebene - index.php inkludiert ja nicht willkürlich alles?
• welchen Vorteil bietet eine _echte_ URL? Also aus Sicht des Benutzers?
• grundsätzliche Logik? Die muss doch eine Anwendung zwingend haben!?

Wie gesagt, so ganz verstehe ich Deinen Post nicht. Ich danke Dir aber für Deine Antwort!

Gruß, Dennis

[hotti]

hi,

• Was haltet Ihr von OOP (speziell im PHP-Kontext)?

In Perl gibt es eine Vielzahl an Verwendungsmöglichkeiten für Objekte, die gar keiner Klasse angehören. Davon mache ich oft und gerne Gebrauch.

• Was haltet Ihr von MVC?

Passt nicht immer.

• Wie baut Ihr Eure Anwendungen auf?

Siehe oben. Wenn es die Aufgabenstellung erlaubt, erstelle ich auch malne Klasse oder Ableitungen/Hierarchien.

• Was kommt bei Euch in den Initialisierungs-, was in den Bootstrap-Prozess?

Genau dazu erstelle ich eine Klasse, weil das immer wieder gebraucht wird. Diese Basisklasse erstellt z.B. bei mir ein Objekt womit die Seite ausgegeben wird. Dieses Objekt erfährt durch bless(), dass es zur Basisklasse gehört und hat Methoden, die z.B. eine HTML-Ausgabe erzeugen können.

Andere Objekte sind z.B. Benutzereingaben, d.h., jedes Submit erzeugt bei mir ein Objekt. Der Parser (GET oder POST) legt die Parameter in den RAM und mein Objekt hat darauf Referenzen, die Variablen sind also nicht doppelt aber doch verfügbar über das Objekt, was nichts weiter ist als eine Sammlung von Referenzen auf Variablen im Hauptspeicher.

Beim Verarbeiten von Benutzereingaben, wird das Eingabeobjekt mit dem Objekt der Basisklasse so verbunden, dass z.B. eine Fehlerbehandlung so erfolgt, dass nicht eine Fehlerseite ausgegeben wird, sondern die Hinweise genau an der Stelle erfolgen, wo eine fehlerhafte Eingabe vorliegt.

• Arbeitet Ihr mit einem Front-Controller? Und wenn ja, wie verwendet Ihr ihn?

MVC Geraffel.

Bei einem CGI ist es wichtig, dass stets ein definierter Zustand vorherrscht. Stichwort State Transition (Zustandsänderungsmodell).

Hotti

[Der-Dennis]

Hey Hotti,

auch Dir erst einmal danke für Deine Antwort.

In Perl gibt es eine Vielzahl an Verwendungsmöglichkeiten für Objekte, die gar keiner Klasse angehören. Davon mache ich oft und gerne Gebrauch.

Von Perl habe ich gar keine Ahnung. Aber größtenteils wird's ja mit PHP - zumindest im OOP Kontext - mit PHP übereinstimmen!?

Andere Objekte sind z.B. Benutzereingaben, d.h., jedes Submit erzeugt bei mir ein Objekt. Der Parser (GET oder POST) legt die Parameter in den RAM und mein Objekt hat darauf Referenzen, die Variablen sind also nicht doppelt aber doch verfügbar über das Objekt, was nichts weiter ist als eine Sammlung von Referenzen auf Variablen im Hauptspeicher.

Halte ich für einen sehr guten Ansatz!

Beim Verarbeiten von Benutzereingaben, wird das Eingabeobjekt mit dem Objekt der Basisklasse so verbunden, dass z.B. eine Fehlerbehandlung so erfolgt, dass nicht eine Fehlerseite ausgegeben wird, sondern die Hinweise genau an der Stelle erfolgen, wo eine fehlerhafte Eingabe vorliegt.

Wie löst Du das prinzipiell? Also wie verbindest Du die Objekte, dass die beschriebene Fehlerbehandlung funktioniert? Ich tue mich mit sowas in der Regel etwas schwer.
Beispiel: Ein einfaches Login-Formular; der Benutzer hat einen falschen Namen oder ein falsches Passwort angegeben. Obwohl ich sehr auf Trennung von Design und Logik bin, überschneiden sich diese an solch einem Punkt immer wieder.

Gruß, Dennis

[hotti]

hi,

Wie löst Du das prinzipiell? Also wie verbindest Du die Objekte,

Genau hier hilft das State Transition Model (STM) und OOP: Das Basisobjekt (HTML-Ausgabe der Seite) wächst mit den Eingaben (Params->Attribute). Die Eingaben werden geprüft, da wo Fehler sind kommt der Fehlertext hin. Und es gibt ein zusätzliches Attribut, was den State (Zustand) beschreibt. Ist das Objekt fertig, wird die Seite ausgegeben, d.h., für diese Ausgabe ist dann nur noch der Zustand entscheidend, ggf. gibt es Platzhalter für Hinweise (1).

Mit STM beschreibst Du also die verschiedenen Zustände, die eine Seite (HTML Response) annehmen kann (aufgrund Request) und mit OOP (Basisobjekt) plus der Methoden erfolgt die Ausgabe.

Beispiel: Ein einfaches Login-Formular; der Benutzer hat einen falschen Namen oder ein falsches Passwort angegeben.

(1) State: unvollständig/fehlerhaft. Das Formular wird nochmal gezeigt, solange bis alles stimmt.

Hotti

@dedlfix: Klaro, habs gelesen. Es gibt halt unterschiedliche Ansätze. Der STM-Ansatz bringt hinsichtlich Einbau von Ajax klare Vorteile, weil: Im Objekt (Basisobjekt, Response-Object RO) sind alle Attribute, die für eine Response erforderlich sind. Ist JS verfügbar (Ajaxrequest), wird mit dem RO eine Ajax-Response erzeugt, im einfachsten Fall wird das RO lediglich serialisiert zum UA geschickt, ist ja alles drin. Ohne JS (normaler Request, Submit o.ä.) wird mit dem RO eine neue Seite erzeugt und ausgegeben.

[Der-Dennis]

Hey hotti,

Genau hier hilft das State Transition Model (STM) und OOP: Das Basisobjekt (HTML-Ausgabe der Seite) wächst mit den Eingaben (Params->Attribute). Die Eingaben werden geprüft, da wo Fehler sind kommt der Fehlertext hin. Und es gibt ein zusätzliches Attribut, was den State (Zustand) beschreibt. Ist das Objekt fertig, wird die Seite ausgegeben, d.h., für diese Ausgabe ist dann nur noch der Zustand entscheidend, ggf. gibt es Platzhalter für Hinweise (1).

Mit STM beschreibst Du also die verschiedenen Zustände, die eine Seite (HTML Response) annehmen kann (aufgrund Request) und mit OOP (Basisobjekt) plus der Methoden erfolgt die Ausgabe.

auch wenn ich mich noch nie mit dem STM beschäftigt habe mache ich in meinen Anwendung wohl etwas ähnliches.
Alle Antwort-Daten (oder besser: Ausgabe-Daten) werden von den Controllern in einem View-Objekt abgelegt. Tritt ein Fehler auf, so melden die Controller dies an den Front-Controller (deshalb nenne ich den Front-Controller, wie in einem anderen Post beschrieben, "höchste Instanz").
Der Front-Controller entscheidet nun aufgrund der Meldung, wie weiter Verfahren werden soll. Ist "alles halb zu wild" und kann die Kontrolle wieder zurück an den aufrufenden Controller gegeben werden? Soll ein anderer Controller aufregufen werden um dieses Problem zu lösen? Soll eine Fehlerseite ausgegeben werden und wenn ja, welcher Header soll gesendet werden?

Wenn ich Dich vorher richtig verstanden habe geht das doch in die Richtung des STM!? Oder hab ich das falsch verstanden?

Gruß, Dennis

[hotti]

hi,

Wenn ich Dich vorher richtig verstanden habe geht das doch in die Richtung des STM!? Oder hab ich das falsch verstanden?

Im Prinzip ja, irgendwie ist das alles ähnlich. STM konsequent nutzen ist die Herangehensweise vom Ergebnis/Ausgabe her, im ersten Schritt werden mögliche Ausgabeseiten (Zustände) skizziert und darauf setzt das Programm dann auf. Freilich gibt es dazu auch Kontrollfunktionen, nuhr, die stehen halt nicht obendran (1). Kontrolliert werden hauptsächlich die Benutzereingaben, alles Andere, also die Ausgabe geht dann sozusagen automatisch am Stück.

(1) Bei meinen CGIs steht obendran eine Kontrollstruktur, in welcher die zu erwartenden Parameter abgehandelt werden. Danach leiten sich die möglichen Zustände ab, eine HTML-Seite wird blockweise erzeugt jedoch immer mit dem ResponseObject. Funktionen, die Eingaben prüfen, geben ein Objekt zurück, was den Zustand beschreibt. Sofern Eingabeprüfungen auch in anderen Anwendungen wiederkehrende Routinen sind, baue ich die in die Basiklasse ein. Dann kriegt die Prüffunktion gleich das ResponseObject bzw. wird damit aufgerufen, ist eine Object-Method und baut die entsprechenden Attribute ein sowie den State->Zustand->OK->Seite kann raus oder es ergibt sich ein anderer Zustand. Einen Frontend-Controler im Sinne einer ZentralUnit gibt es bei mir nicht.

Auf jeden Fall passt OOP ganz gut auf CGI-Aufgaben, wie gesagt, _ein_ Objekt für die Ausgabe, entweder eine komplette Seite oder eine AjaxResponse kann mit diesem einen Objekt erzeugt werden. Im ResponseObject stecken alle Atribute für eine HTML-Seite wie title, meta-descr, author usw. sowie weitere Attribute für den zu erstellenden Body. Bei Ajax gehen nur letztere raus, die Seite ist ja schon da, nur das Ergebnis ist da noch einzubauen. Perl kommt der Sache entgegen, ein ResponseObject wird bei mir später so aussehen:

bisher alles in Einem aber flache Struktur:

  
$ro->{title};  
$ro->{descr}; usw.  
$ro->{uhrzeit_als_Beispiel}  

später auch alles drin, aber unterteilt in HTML und AJAX:

  
$ro->{HTML}->{title} = 'foo';  
$ro->{HTML}->{descr} = 'bar';  
$ro->{AJAX}->{uhrzeit_als_Beispiel}  

Das macht das Löschen einfach, für Ajax wird mit
delete $ro->{HTML};
alles rausgeschmissen, was nicht gebraucht wird, dann serialisiert und ab als Response.

Hotti

[Der-Dennis]

Hi Hotti,

Wenn ich Dich vorher richtig verstanden habe geht das doch in die Richtung des STM!? Oder hab ich das falsch verstanden?

Im Prinzip ja, irgendwie ist das alles ähnlich. STM konsequent nutzen ist die Herangehensweise vom Ergebnis/Ausgabe her, im ersten Schritt werden mögliche Ausgabeseiten (Zustände) skizziert und darauf setzt das Programm dann auf.

gut, dann ist das ja tatsächlich nicht weit voneinander entfernt.

Einen Frontend-Controler im Sinne einer ZentralUnit gibt es bei mir nicht.

Gibt es dafür einen speziellen Grund? Ich hielt das bis jetzt als die beste Möglichkeit. Also prinzipiell in Anlehnung an ein Betriebssystem, dass die Ressourcen verwaltet und auf die einzelnen Aufgaben verteilt.

später auch alles drin, aber unterteilt in HTML und AJAX:

$ro->{HTML}->{title} = 'foo';
$ro->{HTML}->{descr} = 'bar';
$ro->{AJAX}->{uhrzeit_als_Beispiel}

>   
> Das macht das Löschen einfach, für Ajax wird mit  
> delete $ro->{HTML};  
> alles rausgeschmissen, was nicht gebraucht wird, dann serialisiert und ab als Response.  
  
Das ist super, auf so eine Idee bin ich bis jetzt noch nicht gekommen. Ajax und HTML bedienen sich bei mir zweier unterschiedlicher View- und Response-Objekte; mit dem Resultat, dass es einiges an doppeltem Code gibt. Das werde ich in Zukunft auf jeden Fall berücksichtigen.  
  
Gruß, Dennis

[fastix®]

Moin!

Beispiel: Ein einfaches Login-Formular; der Benutzer hat einen falschen Namen oder ein falsches Passwort angegeben.

(1) State: unvollständig/fehlerhaft. Das Formular wird nochmal gezeigt, solange bis alles stimmt.

Schlechtes Beispiel. Schon aus Gründen der Sicherheit ist es immer eine gute Idee alles, was mit Authentifizierungen zu tun hat, so einfach wie möglich zu halten.

Also sieht ein Login-Skript für einen Admin-Bereich bei mir so aus:

<?ebb #execute by brain  
if (Überhaupt erwartete Daten gesendet?) {  
     if (Auth erfolgreich?) {  
           session starten;  
           Auth registrieren;  
           ggf. FailZähler Löschen;  
           ggf. Weiterleitung oder include der Zielseite aus session, sonst standard-Seite  
           exit;  
     }  
     ggf. FailZähler setzen, prüfen, und im Ernstfall reagieren -> (Bei mir gerne: Zugriffsverbot in .htaccess);  
     ggf. mesg setzen;  
}  
  
ggf. {  
     primitives Template laden  
     ggf. mesg. einfügen  
     zeigen;  
} else {  
     Formular + ggf. mesg. zeigen;  
} # immer:  
exit;  
?>

Die zu schützenden Scripte bekommen, bevor irgendetwas anderes getan wird als Einzeiler mit require ein include (Weil es ein Einzeiler + Kommentar ist) auferlegt:

<?ebb  
session starten;  
if (Auth nicht registriert oder ungültig?) {  
     ggf. aktuelle Seite als Zielseite in Session schreiben;  
     ggf. mesg. setzen (z.B. "He! Du MF: Machst Du ScheißCookies an!");  
     ggf. Weiterleitung zum Login; # oder  
     ggf. böses die(); #siehe 2 Zeilen weiter oben # oder:  
     ggf. 403er header; # immer:  
     exit;  
}  
# Wer hier noch "lebt" ist berechtigt: EOI (end of include); auto: back zum #main  

Alles, was hinter "ggf." steht sind optionale Aufgaben, die über die Authentifizierung an sich hinausgehen.

Das sind alles "Wenigzeiler" oder die von mir besprochenen Nägel und ich glaube fest daran, dass jeder hierfür unnötige Befehl eine Fehlerquelle ist. Also sind Login-Geschichten Direktkandidaten für transparentes, schnödes, pragmatisches, prozedurales Programmieren (soweit wie keine nativen Objekte der Sprache oder des Template-Systems) benutzt werden können) ohne formalen Überbau.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Tom]

Hello,

if (Auth erfolgreich?) {
           session starten;
           Auth registrieren;
           ggf. FailZähler Löschen;
           ggf. Weiterleitung oder include der Zielseite aus session, sonst standard-Seite
           exit;
     }

welchen Fail-Zähler setzt und loschst Du da?

Wenn die Session Bestandteil der Authentifizierung und nicht die Authentifizierung Bestandteil der Session ist, wie verwaltest Du dann den Fail-Zähler?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[fastix®]

Moin!

welchen Fail-Zähler setzt und loschst Du da?

Fehlgeschlagene Logins per IP-Adresse. Gegen Brute-Force-Angriffe. Ich weiß, das birgt auch Probleme. Es gibt da aber keine Vorgehensweise, die vollkommen unproblematisch ist. Im Zweifelsfall kann man auch noch ein Mail an den Admin senden: "ip .... wegen vermuteter DDoS-Attacke gesperrt". Das ist aber nur eine Zeile.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[dedlfix]

Hi!

Andere Objekte sind z.B. Benutzereingaben, d.h., jedes Submit erzeugt bei mir ein Objekt. Der Parser (GET oder POST) legt die Parameter in den RAM und mein Objekt hat darauf Referenzen, die Variablen sind also nicht doppelt aber doch verfügbar über das Objekt, was nichts weiter ist als eine Sammlung von Referenzen auf Variablen im Hauptspeicher.

Das beispielsweise auf PHP zu übertragen ist nicht unbedingt sinnvoll, weil PHP seine eigene Philosophie hat, mit Benutzereingaben umzugehen. Sie sind bereits fertig in $_GET/$_POST abgelegt, müssen also nicht erst noch selbst geparst werden. Man braucht auch aus technischer Sicht keine Referenzen oder dergleichen darauf. Und selbst wenn man das gesamte $_POST- oder $_GET-Array oder einzelne Werte daraus in andere Variablen kopiert, so findet intern erst einmal kein Kopiervorgang statt. PHP verwendet, solange beide Werte nicht auseinanderlaufen, für den Anwender unbemerkt eine Quasi-Referenz. Das Umkopieren findet erst bei Änderungen statt.

• Arbeitet Ihr mit einem Front-Controller? Und wenn ja, wie verwendet Ihr ihn?
  MVC Geraffel.

Nein, MVC und Front-Controller sind zwei unabhängige Patterns. Obwohl sie häufig zusammen auftauchen, kann man sie auch einzeln verwenden. Wenn du eine Instanz hast, die sich in der Regel um das Delegieren von eingehenden Requests an Stellen, die die Abarbeitung vornehmen, kümmert, dann ist das im Prinzip ein Front-Controller, auch wennn du ihn nicht so nennen magst.

Lo!

[Der-Dennis]

Hallo zusammen,

hiermit möchte ich mich noch einmal bei allen für die Diskussion und die beigetragenen Meinungen bedanken.

Gruß und vielen Dank, Dennis