Das ist auch nicht so sehr verschieden vom OOP anderer Programmiersprachen (klar gibt es auch hier Ausnahmen).
Es gibt aber einige gute Tutorials bzgl. OOP in PHP5. Vielleicht ist das hier einen Blick wert.

Meinen Vorrednern kann ich mich anschließen.
Gute Ansätze hast du in deinem CMS, aber man kann noch viel machen, um es zukunftsfähiger auszurichten.

Zitat von Valle:

Ich kann dir als Referenz auch noch das Zend Framework empfehlen. Jenes ist zwar sehr langsam, als technischer Ansatz aber sicher einen Blick wert. Deren API, die abstrakte Implementation und das gesamte Konzept ist sehr gut Durchdacht und meiner Meinung nach echt lobenswert.

*hust* Da geht sie dahin, die Einigkeit. ZF ist nicht langsam - es hat aber einen gewissen Overhead wie jedes andere Full-Stack-Framework auch. Auf normaler Hardware und mit nem Opcode-Cache (aptitude install php-apc) ist die Performance sehr gut. Im Zweifel schicke ich dir mal ein paar Infos zu ZF-Applikationen mit denen ich beruflich zu tun habe. Da aenderst du dann gerne deine Meinung

Um noch kurz ein paar allgemeine Worte zum ZF zu verlieren: es verfolgt zwar denselben Ansatz wie Symfony (Full-Stack MVC-Framework), aber auf eine ganz andere Art und Weise (Symfony setzt auf Code Generation, Zend Framework laesst dich alles selbst machen). Fuer den Einstieg wuerde ich auf alle Faelle Symfony empfehlen, behalte aber die Ideen und Konzepte von ZF im Blick.

@himitsu: wenn du gerade erst PHP5 lernst, dann nutze die Chance und fang gleich mit MVC an. Dieses bisherige include functions.php Gefrickel ist Schnee von Gestern

Greetz
alcaeus

Was wäre denn heutzutage die Alternative zu diesem "include-Gefrickel"?
Also wie kann ich mir die Umsetzung von MVC an dieser Stelle vorstellen?


Grüße,
Frederic

So umfangreich dass ich es hier nicht posten will. Da geschieht naemlich viel im Hintergrund. Mal ein Beispiel:

du rufst die URL hxxp://foo.bar/user/showprofile/alcaeus auf.
Uebers Routing habe ich folgendes URL-Schema definiert:
user/showprofile/:username

In diesem Fall leitet mich also der Controller ins user-Modul (Definiert durch die Klasse userActions) um und verlangt die Action showprofile (definiert durch die Methode executeShowprofile). Zusaetzlich wird der GET-Parameter "username" auf "alcaeus" gesetzt.
Dort lauf ich ins Model, um mir die Daten des Benutzers mit dem Namen "alcaeus" raussuchen zu lassen. Die Daten uebergebe ich an die View (einen Block HTML/PHP-Mischung, ein Smarty-Script, ein Twig-Template, etc.), welche im Hintergrund gerendert und ausgegeben wird.

Das wars jetzt kurz zusammengefasst - ein Blick durch die Einsteiger-Tutorials macht das eventuell noch verstaendlicher

Greetz
alcaeus

Hallo,

@himitsu: Nun, deine Session und Kekse Verwaltung liest sich nicht so toll, wenn alles in einer Datei steckt. Ich kann dir nur sagen, dass ich für Sessions bisher immer mit PHPs eigenen Session-Funktionen gut aus kam und diese auch weiterhin bevorzuge.

@alcaeus: Ich muss gestehen, dass ich diese Information von einem Freund blind übernommen habe, der wie ich finde durchaus Ahnung von der Materie hat. Ich habe selbst mit Zend schon öfter mal was angefangen, aber bisher nichts wirklich am laufen. Wenn du sagst Zend wäre nicht langsam, dann glaube ich dir das auch. Solange ich selbst nicht Hand angelegt habe, kann ich wohl nur auf andere Meinungen verweisen.

Liebe Grüße,
Valle

Moin,

ich hab grad nochmal nen Blick in den Code geworfen. Nach PHP_Include() habe ich aufgegeben. Hier mal ein paar Punkte dazu:

• der erste Parameter heisst $__file. Trotzdem uebergibst du in index.php5 immer wieder __LINE__. Was denn jetzt?
• Der $__file-Parameter wird fuer die Fehlerbehandlung verwendet. Wenn du schon angeben willst, wo der Fehler seinen Ursprung hatte, guck dir mal debug_backtrace() an. Stack-Traces sind was Tolles
• markieren

  PHP-Quellcode:

  if ($AddScriptDir) $FileName = (@$Config['Scripts'] ? $Config['Scripts']
        : ($Config['RootPath'] ? $Config['RootPath'] . 'Scripts/' : dirname(__FILE__) . '/')) . $FileName;
  Soll ich? Also:
  • Gewoehn dir an, immer Klammerbloecke hinzuzufuegen.
  • Everytime you use "@", God kills a Kitten. Im Ernst, wenn du pruefen willst ob $Config['Scripts'] gesetzt ist und keine E_WARNING kassieren willst, pruef mit isset().
  • Tertiaere Operatoren ($foo ? 'bar' : 'baz') sind spaerlich zu nutzen. Das kann schnell mal schiefgehn.
  • Verschachtelte Tertiaere Operatoren sind noch viel schlimmer.
• Ok, weiter im Programm:
  
  markieren

  PHP-Quellcode:

  $FileName = preg_replace('#\.php$#i', $Config['Ext'] ? $Config['Ext'] : ((($X = dirname(__FILE__)
        . '/Functions.*') && ($Y = glob($X))) ? substr($Y[0], strlen($X) - 2) : '.php'), $FileName);
  Siehe oben. Ich fang jetzt gar nicht weiter an, vielleicht magst du den Code ja kurz erklaeren.
• Log_WriteFile: schmeiss lieber ne Exception und registrier nen Exception-Handler (set_exception_handler()). So kannst du in der Applikation auch individuell auf Fehler reagieren.

Und um die ganze Funktion ad absurdum zu fuehren: guck dir mal set_include_path() an. Auch das bereits erwaehnte spl_autoload ersparen dir da einige WTF-Momente.

BTW, ich hab den Code jetzt mal durch PHPMD gejagt. Allein die Funktion Main_Initialize() hat ne Cyclomatic Complexity von 74 (alles ueber 10 gilt als unwartbar) und ne NPath von 1067489280. Das bedeutet dass es ueber eine Million Ausfuehrungspfade durch die Funktion gibt. Alles ueber 300 sollte da refactored werden. Ich hab dir mal das Ergebnis angehaengt - mehr Informationen findest du auf der obigen Webseite.

@Valle: ein oft gemachter Fehler ist, dass eben der Opcode-Cache weggelassen wird. Das geht auf Dauer echt auf die Performance. Ich kann aber von der Performance nichts schlechtes berichten, und das bei echt grossen Anwendungen (mehrere 100k LOC).

Greetz
alcaeus

Ach, und noch was: ich hab nur kurz ueber die Functions.php5 drueber geguckt, aber die Sicherheitsluecke in Main_Fialize() bei aktiviertem Debug-Mode ist schon schnuckelig. So einfach war es noch nie, HTML-Code in die Seite reinzupruegeln. Cross-Site-Scripting wie man will. Auch wenns der Debug-Mode ist, die direkte Ausgabe von GPC-Variablen ist ne saudumme Idee.

Greetz
alcaeus

Mhm...ich will da jetzt auch was lernen, damit mir das selbst nicht passiert

Wie könnte man denn nun damit eine Cross-Site-Scripting Attacke fahren bzw. wo liegt denn jetzt die böse Lücke?

Zitat von blackfin:

Mhm...ich will da jetzt auch was lernen, damit mir das selbst nicht passiert

Wie könnte man denn nun damit eine Cross-Site-Scripting Attacke fahren bzw. wo liegt denn jetzt die böse Lücke?

Simpel, es wird dort alles ausgegeben was z.B. im get Array ist. Somit muss man da nur etwas java script reinpacken und man kann mit dem zielrechner (also der jenige der ein link zur präparierten seite bekommt) machen was man will(dein Antivirenprogramm hilft nicht wenn man über ne IE/Chrome/... Lücke und etwas JS kompletten zugriff auf das system bekommt ==> ja das geht)

Wenn ich das jetzt richtig verstanden habe. ist das aber nur deswegen eine Sicherheitslücke, da die GPC-Variablen vor der Ausgabe nicht gefiltert / escaped werden, so dass man eben auch JS-Code per GET oder POST einschleifen kann, richtig?
Würde man die Variablen vorher überprüfen und analog dem Konzept "traue keinem User-Input" vorgehen, wäre die Debug-Ausgabe ja kein Problem mehr.
Oder habe ich es nun doch nicht gepeilt...