Bleppo

Hallo PHP-Forum,
ich bin etwas ratlos. Ich arbeite mit jemandem an einem PHP-Projekt, das wahrscheinlich recht groß werden wird. Wir benutzen daher kein Framework und schreiben uns unsere eigene Architektur, die wir flexibel und genau auf unsere Bedürfnisse anpassen können.

Unser Problem: Wir sind bei der Verzeichnisstruktur und der grundsätzlichen Organisation der Dateien verschiedener Meinung. Er will es so wie viele Frameworks machen, d.h. schön einen Ordner für Templates, wo einfach alle Templates reingeschmissen werden, einen Ordner "classes", einen Ordner für Sprachdateien, einen für Formulare usw. Sein Argument ist: "Alle machen das so. Und so ist es schön strukturiert und man weiß, was wo hin gehört."

Was mich daran stört, ist, dass sich die Dateien dann über die gesamte Verzeichnisstruktur verstreuen. Ich will, dass die Dateien immer dort liegen, wo sie zusammen ein Modul oder eine Seite bilden. Z.B. habe ich in "pages" einen Ordner "index" für die Startseite und lege dort alles ab, was dazu gehört. Spezial-Klassen, die nur für die Startseite benötigt werden, Templates, Sprachdateien, am besten auch die Stylesheets. Unter "registration" lege ich alles ab, was zur Benutzer-Registrierung gehört, usw. Alles was an anderer Stelle wiederverwendet wird und nicht so spezifisch ist, wird natürlich woanders gespeichert.

Das Projekt wird sehr komplex werden, mit vielen Modulen und Komponenten. Ich denke mir halt, wenn später ein paar mehr Programmierer daran arbeiten, werden sie dankbar sein, wenn man ihnen einfach einen Ordner für ihr Modul gibt, wo sie arbeiten sollen. Sie brauchen es dann nicht an verschiedenen Orten innerhalb der Verzeichnisstruktur zusammenbasteln. Das erhöht die logische Kohäsion.

Jetzt also meine Fragen an euch: Wie seht ihr das? Warum ist es sinnvoll, z.B. alle Templates systemweit an einem Ort zu sammeln? Wie wird das im professionellen Umfeld gehandhabt? Warum sammelt z.B. CodeIgniter die Controller, Models und Views alle zentral?

Ich meine, dass es da langfristig sehr unübersichtlich werden kann. Sein Gegenargument: "Ja, da kann man ja Unterordner machen." Aber das löst meiner Meinung nach nicht das Grundproblem, dass wenn ich an einem Modul arbeite, ich nicht weiß, wo sonst noch was davon im Dateisystem herumliegt.

Ich bin dankbar für jede Antwort.

Mister Ad

nikosch

Da hakt die Idee das erste mal. In diesem Fall bekommst Du sehr komplexe Verzeichnisse für die public Ressourcen, die Du dann immer an die zuständigen Templates durchreichen musst, möglicherweise sogar noch relativ zu einem Stammpfad auflösen usw. Und stelle Dir erstmal die Verknüpfung der Ressourcen untereinander vor. Z.B. ein Stylesheet, das ein Bild über background-url einbindet.
Zudem hast Du dann die Situation dass die gesamten anderen Teile bis zur Tiefe dieser Ressourcen zwingend im DocRoot liegen müssen (und damit tendenziell öffentlich aufrufbar sind (z.B. über cUrl) ODER du alle Ressourcen durch PHP-Scripte schleifen musst. Ich verstehe Deine Intention (gerade für Applikationen mit variablen Modulen ist das praktisch bei deren Installation), die Pflege der einzelnen Komponenten wird durch solche Verzeichnisstrukturen allerdings ziemlich aufwendig.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Bleppo

Ja. Das mit den Stylesheets stimmt. Habe ich auch schon überlegt, dass hier ein Public-Ordner besser wäre, in dem sowas gesammelt wird. Die Bilder, Javascripte, CSS-Dateien, usw. In diesem Fall bin ich mit der Streuung einverstanden. Aber was ist mit dem Rest? Die ganze PHP-Infrastruktur? Wie zentralisiert man die sinnvoll?

fab

Bei einem großen modular aufgebauten Projekt ist es schon sinnvoll, für jedes Modul ein eigenes Oberverzeichnis anzulegen und ja, das wird in der Regel auch von Frameworks unterstützt (siehe z.B. http://framework.zend.com/manual/1.1...e.project.html, auch als Anregung für dich)

Zu den Argumenten deines Kollegen
Das machen ganz sicher nicht alle so und ich glaube auch nicht dass ihr euch so etwas wie Wordpress zum Vorbild nehmen wollt. "Schön strukturiert" scheint Ansichtssache zu sein, meiner Meinung nach wäre das eher ein Punkt für deinen Ansatz. Und was hat man davon, ohne nachzudenken zu wissen, wo etwas hinkommt, es dann aber nicht wiederzufinden wenn man es braucht? Letzteres sollte Priorität haben, also steckt man doch besser zusammen, was logisch zusammengehört.

Wenn du die Verzeichnisse als Packages siehst, kannst du auch mit den OOP Prinzipien zur Package-Kohäsion argumentieren (insbesondere dem Common Reuse Principle) und sie als weitere Richtlinie verwenden.

__________________
PHP Blog + Library
CSS Effects + Tools

xm22

Es gibt im Prinzip 2 verschiedene Ansätze:
1. Alle zu einem "Modul" gehörende Dateien bündeln (CSS, Bilder, etc. mal außen vor)
2. Alle zu einer Applikationsschicht gehörenden Dateien bündeln

Bei 1. hat man den Vorteil, dass man komplette "Pakete" hat, was die Modifizierung und Austauschbarkeit in der Praxis doch enorm erhöht.
Bei 2. hat man dafür eine einfachere Möglichkeit des "Themings"
Beide Ansätze sind verbreitet, 2. allerdings wesentlich mehr. Was man nun anwenden möchte, muss man für sich entscheiden.
Eine Sache ist allerdings immer empfehlenswert: Bilder, css, etc. in ein Verzeichnis, dass innerhalb des Document-Root liegt, die eigentliche Applikation hingegen außerhalb des Document-Root.

Koala

beide Ansätze sind nebeneinander denkbar:

- alle Dateien schön sortiert in die jeweiligen Verzeichnisse (templates, css, js usw.).

- Module kommen in das Verzeichnis "module" mit allen zugehörigen Dateien in einer
Verzeichnisstruktur welcher der des Stammverzeichnis entspricht.
Eine install.php kopiert die Dateien dann entsprechend der Struktur.

Sieht dann also so aus:

module:

module/modul1:

- install.xml

- install.php

- root/css/modul1.css
- root/js/modul1.js
- root/templates/modul1.tpl

Wird bei phpbb so gemacht und find ich recht praktisch

Es ist jederzeit nachvollziehbar wo die Dateien hinkopiert wurden
und wo sie herkommen.

__________________
Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.