[envo-media]

Hi Leute,

In Programmierbüchern lernt man das Grundprinzip der Programmierung und wie man mit der jeweiligen Sprache arbeitet. Jedoch wird meistens nichts darüber gesagt wie man seine Projektdaten am besten verwaltet. Daher dachte ich mir, ich poste mein Konzept zur Projektdatenverwaltung und -nutzung. Erstmal wird festgestellt welche Technologien und davon ableitende Konzepte man verwenden möchte. Zum Beispiel arbeite ich meistens mit PHP und Javacript. Aber nicht jede PHP-Datei ist ein Objekt, manche gehören sogar direkt zur Homepage. Daher werden 2 Überordner Website (inhalte für die Website) und Static (statische Inhalte wie klassen etc.) erstellt.

Ordnergrundstruktur

Zu allerst haben wir unser Hauptverzeichnis. In dem habe ich die Ordner Website und Static angelegt.

Den Ordner Website habe ich nochmal Content, Images, Modules (unterteilt sich nochmal ind die jeweilige Technologie unterteilt PHP, Javascript, etc. und bietet Erweiterungen für das Grundgerüst /Static) unterteilt.
Im Ordner werden dann Ordner für die Jeweilige Technologie PHP, Javascript, etc. erstellt, die sich dann noch mal ggf. in Class und Functions unterteilen.

Die Ordner-Struktur sieht nun wie folgt aus:
Hauptordner

/Website
/Content
/Images
/Modules

/PHP
/Javascript




Static
/PHP

/Class
/Functions

/Javascript

Mit zwei PHP-Dateien im Hauptordner gebe ich meiner Projektdatenverwaltung noch den letzten Schliff.

Config.php

In der Config.php werden Konstanten definiert, damit sie nicht durch Variblaen überschrieben werden und auch nur einmal editiert werden müssen.
"MY" ist diesem Fall ein Prefix. Die Konstanten sind freiwählbar.

[bacon]

Ich finds ganz schön cool, dass du dir die Mühe gibst. Das Konzept an sich macht aber so eigentlich keinen großen Sinn, bzw. vielleicht solltest du noch kurz erläutern, was in den einzelnen Ordnern GENAU abgelegt wird. Im Groben jedenfalls wirkt es etwas altbacken, bzw. aus PHP4-Zeiten stammend. Generell ist es aber immer gut, seine sicherheitskritischen PHP-Libraries außerhalb des Webroots zu verwalten, insofern ist dein Ansatz ganz gewitzt - gesetzt den Fall, /Website ist auch tatsächlich das webroot (also "/"). Ansonsten würde es überhaupt keinen Sinn machen. Auch der Ordner "Module" im Webroot - was macht der dort? Da liegen doch auch php-files drin, oder? Warum nicht alles, was php enthält, direkt aus dem Webroot entfernen und nur den Hauptcontroller (index.php) drin lassen?

Dein Include-Statement ist der gröbste Fehler. NIEMALS Request-Variablen ungeprüft verwenden, erst recht nicht in require/include-Anweisungen.

Zum Thema mod_rewrite: Es macht immer Sinn, ALLE Anfragen, die nicht auf eine Projektressource (css, js, Bilder etc...) gehen, auf den Hauptcontroller (index.php) zu leiten. Dann kannst du per $_SERVER['REQUEST_URI']-Umgebungsvariabel die komplette URI anschauen und ziemlich flexibel Routing-Regeln aufstellen. Dann musst du nicht ständig deine mod-rewrite regexe verwalten.

Vielleicht wirfst du auch einen Blick auf die autoload()-Funktion bzw. noch besser spl_autoload_register() etc.

Ob man eine PHP-getriebene Website prozedural oder objektorientiert aufbaut, ist sicher eine Grundsatzdiskussion, die hier nicht hingehört. Trotzdem solltest du dir vielleicht mal das Konzept von Namespaces anschauen (kommt auch nativ mit php5.3), dann bekommst du vielleicht ne Idee, was noch so alles geht.

Nach allem würde ich das ganze nochmal überdenken - es macht nämlich tatsächlich Sinn, seine Dateien strukturiert abzulegen. Ein möglicher Ansatz wird hier beschrieben: http://www.phpguru.org/static/ApplicationStructure.html

Wenn du ein wenig Erfahrung gesammelt hast, macht es bestimmt auch Sinn, sich mal ein PHP-Framework wie bspw. Zend oder Symfony anzuschauen.

[envo-media]

-Vielen Dank für deinen Beitrag. Mit der __autoload-Funktion habe ich mich scon belesen. Jedoch finde ich nichts Konkretes zu den spl Funktionen, bzw. auf PHP.net verstehe ich die Funktionsweise nicht. gibt es Vlt. ein Dokumentation oder ähnliches dazu?

MfG

[bacon]

Es gibt etwas versteckt die API-Doku:
http://php.net/~helly/php/ext/spl/

Viele Dinge erschließen sich daraus bereits, man muss aber auch sagen, dass viele der bereitgestellten Klassen auch Grundwissen über Software-Entwurfsmuster voraus setzen. Trotzdem ist es überhaupt gar nicht schlecht, sich damit mal auseinander zu setzen, vornehmlich mit den gof-pattern: http://de.wikipedia.org/wiki/Viererbande_(Softwareentwicklung)