Verzeichnisstruktur für ein CMS

[DerWuff]

Hallo allerseits.

Da ich des öfteren mal kleine Websites erstelle, möchte ich mir nun endlich mal ein eigenes kleines CMS programmieren. Natürlich mit dem Zend Framework. :)

Dazu habe ich mir folgende Verezichnisstruktur überlegt:

application
....admin
........controllers
....data
........config.xml
........admin_navigation.xm
....modules
........default
............controller
............views
............models
........user
............controller
............views
............models
........navigation
............controller
............views
............models
....templates
........meindesign
............modules
................default
................user
................navigation
............images
............styles
............index.phtml
library
....Zend
public
tmp
index.php
.htaccess


Das eigentliche CMS befindet sich im admin Verzeichnis, welches die aufgerufenen Controller und Actions an das jeweilige Modul weiterleitet.

Die Views für den Adminbereich befinden sich in den view Verzeichnissen im modules Ordner. Die Views (sowie Bilder und Stylesheets) für das Frontend befinden sich hingegen in einem Unterverzeichnis (z.B. meindesign) im Ordner templates.

Was ich z.B. noch nicht weiss, ist wohin ich die Bilder und Styles für den Adminbereich ablegen soll.

Was haltet ihr von dieser Aufteilung?

[deetee]

Du hast styles und images im Verzeichnis templates/meindesign , aber das ist nicht öffentlich erreichbar. Das wird wohl so nicht funktionieren.

[KingCrunch]

Willkommen im Forum :)

Du hast styles und images im Verzeichnis templates/meindesign , aber das ist nicht öffentlich erreichbar. Das wird wohl so nicht funktionieren.
Die index.php liegt im root, weswegen anscheinend die komplette Struktur im Public liegt Oo

Son paar Sachen dann nochmal von mir:
- Was habt ihr eigentlich alle gegen die Beispielstruktur aussm Manual? :D zB muss "admin" denn unbedingt ausserhalb der eigentlich Struktur, anstatt regulär ins moduls-Verzeichnis? Mal davon abgesehen wirkt sie sehr Standard, es gibt also wenig auszusetzen. Im Standard ist im application-Order noch ein Verzeichnis views vorhanden, welches zB standardmässig von Layout verwendet wird.
- Wie gesagt ist der komplette Baum anscheinend öffentlich erreichbar, was ernste Sicherheitsrisiken mit sich bringen kann.
- Styles und Images sind HTML-spezifisch, haben insofern wenig mit PHP und noch weniger mit ZF zu tun. Kurz: Ist eigentlich wurscht, wo die liegen, solange die Links stimmen ;) Wichtig hier aber, dass sie von aussen erreichbar sind, weil der Browser sie abruft, nicht PHP oder der Webserver. Denkbar wäre auch sie durch PHP durchzuschleifen, dies würde den Server aber unnötig belasten, weil dadurch jedes einzelne Bild und jedes Style nen eigenen Request abschickt, der von PHP bearbeitet wird.

[DerWuff]

Hallo zusammen.

Ihr habt recht. Das Template Verzeichnis sollte ich wohl ins public Verzeichnis schieben. Der Ordner application und library sind eigentlich nur provisorisch im public, die kommen später eine Stufe höher.

Leider weiss ich nicht wie ich das mit dem Adminbereich in der Standardstruktur umsetzen soll; ich blick da irgendwie noch nicht so richtig durch. :)

Danke für eure Hilfe.

[KingCrunch]

Hallo zusammen.

Ihr habt recht. Das Template Verzeichnis sollte ich wohl ins public Verzeichnis schieben. Der Ordner application und library sind eigentlich nur provisorisch im public, die kommen später eine Stufe höher.

Leider weiss ich nicht wie ich das mit dem Adminbereich in der Standardstruktur umsetzen soll; ich blick da irgendwie noch nicht so richtig durch. :)

Danke für eure Hilfe.Was spricht dagegen es als weiteres Modul zu setzen?

[deetee]

Leider weiss ich nicht wie ich das mit dem Adminbereich in der Standardstruktur umsetzen soll; ich blick da irgendwie noch nicht so richtig durch.

Ich würde empfehlen jedem Modul einen eigenen Adminbereich zu spendieren. Diese kann man dann später einem allgemeinen Adminbereich hinzufügen, sodass alle Adminbereiche über einen zentralen Adminbereich erreichbar sind.

Das würde die Modularisierung konsequent weiterführen. Es ist nämlich was anderes ein Modul zu schreiben, welches von nur der Applikation genutzt werden kann für die es geschrieben wurde, oder ein Modul zu schreiben, welches so flexibel ist, dass es leicht in andere Applikationen eingefügt und genutzt werden kann. Letzteres ist wesentlich aufwendiger, aber echte Modularisierung.

[zf-neuling]

Ich würde empfehlen jedem Modul einen eigenen Adminbereich zu spendieren.

So sollte es auch sein, wenn man modular arbeiten möchte. Das Problem ist hier wie ich sehe, dass die meisten Entwickler eine bestimmte Struktur haben möchten und zwar

www.domain.de/admin/modul/controller/action

und nicht

www.domain.de/modul/admin/controller/action

Die erste Variante ziehe ich auch vor, hab leider nicht geschaft es so umzusetzen :o

[Akido]

da dies mein erster Beitrag hier im Forum ist erstmal: Hallo Zusammen!

also, ich bin mit MVC auch noch nicht wirklich vertraut und plane ebenfalls eine art CMS zu programmieren, von daher kanns gut sein dass ich jetzt den totalen schmarrn schreibe...

aber wie wärs einen eigenen Bootstrapper für den Adminbereich zu schreiben?
also 2 publics anlegen, eins fürs Frontend und eins fürs Backend?

evtl. den Adminbereich dann auch nur über ne Subdomain erreichbar machen würde bestimmt auch noch zur sicherheit beitragen, oder?

[Mike]

also 2 publics anlegen, eins fürs Frontend und eins fürs Backend?Welchen Vorteil siehst du denn dabei?

den Adminbereich dann auch nur über ne Subdomain erreichbar machen würde bestimmt auch noch zur sicherheit beitragen, oder?Auch hier seh ich keinen Gewinn. Den Login zu "verstecken", macht ihn nicht sicherer.

[Akido]

wie gesagt, ich kann mit dem was ich hier sage auch total im aus stehen:

also zum Thema 2 Bootstrapper:
ich kann im Adminbereich z.B. auf die Rechtekontrolle, welche wohl am sinnvollsten in der Boostrapper geladen wird, des Frontends vollkommen verzichten.

zum Thema Subdomain:
"sicherer" wird es natürlich nicht. aber ich erschwere einem evtl. Angreifer die Arbeit.

oder???

[Mike]

"sicherer" wird es natürlich nicht. aber ich erschwere einem evtl. Angreifer die Arbeit.Als Angreifer würde ich so oder so nur in den seltensten Fällen durch die Vordertür spazieren. IMHO eine Maßnahme ohne sonderlichen Effekt.

ich kann im Adminbereich z.B. auf die Rechtekontrolle, welche wohl am sinnvollsten in der Boostrapper geladen wird, des Frontends vollkommen verzichten. Um das Ganze ACL-Gedöns kümmert sich bei mir ein Plugin. Beim Betrachten des Modulnamens entscheidet das Plugin dann, was in diesem Modul überhaupt benötigt wird.
Da entsteht nicht viel Overhead.
Mehrere Bootstrap-Dateien zu haben, klingt für mich nicht sonderlich hübsch. Ich würde versuchen es anders zu lösen.

[somebody1981]

hallo ihr lieben,

also um das von oben aufzugreifen, ist mir www.xyz.de/backen/modul/controller/action (http://www.xyz.de/backen/modul/controller/action) auch am liebsten und ich finden die idee, dass jedes modul sich in einem admin verwalten lassen muss auch unabdinglich ... ich steh immens auf modular

bei mir isses daher bisher so, dass ich in der config sogenannte branches definiert habe z.B. admin und denen ein spezifisches wort zugeordnet habe z.B. backend ... so kann ich entscheiden, wie die baseurl für admin sein soll. auch habe ich in der config die möglichkeit eingeräumt ein controller-directory-add zu definieren, welches dann im jeweiligen modul schaut ob es branch-spezifische controller gibt. gibt es kein add oder is das modul das default-modul des branch sucht zf in controllers_default. mit views verhält es sih genauso

das sieht dann in der cfg so aus

<branches>
<type_url>
<admin>backend</admin>
</type_url>

<controller_dir_adds>
<admin>admin</admin>
</controller_dir_adds>
</branches>
der jeweilige tagname der branch-type-url definiert damm immer das default-modul für den branch, so dass ich die modulstruktur von zend einhalte.

sieht dann in etwas folgender massen aus
.root
....app
........core
........modules
............admin
...............controllers_default
...............views_default
...............models
.............mod-xy
...............controllers_default
...............controllers_admin
...............views_default
...............views_admin
...............models

wie oben schon angedeutet sorgt ein plugin dafür beim erkennen einer typeurl die baseurl des frontcontrollers etsprechend zu setzen so dass ich bsp. www.xyz.de/backend (http://www.xyz.de/backend) als base habe. das setzen des defaultmodule hier bspw. Admin und die jew. directories erfolgen auf selben wegen (plugin)

nun meine frage an die profis, da ich von dem status ja echt noch immens weit entfernt bin. is das eine passable art und weise oder is das totaler bullshit? gibts da bessere möglichkeiten??

lg
some


p.s.: sorry hab erst jetzt gesehen, dass das thema schon so alt ist ... will das forum aber so ungern mit schon diskutierten themen aufblähen und habe aber immensen nachholebedarf ... sry ;)

[Remi]

Using a Conventional Modular Directory Structure (http://framework.zend.com/manual/en/zend.controller.modular.html)

[somebody1981]

also ich möchte bei weitem nicht vorlaut sein, aber was hat dir jetzt gesagt, dass ich das net tu? abseits des "core" welcher allgemeine sachen und abstraktionen enthält, auf welche alle module zugreifen und ich diesen genau deshalb nicht als modul definieren wollte, isses doch fast genau die struktur???

und ich brauch nunmal für frontend und backend unterschiedliche views bzw. wenn ein "branch" (wie ich es oben aus jugendlichem leichtsinn getauft hatte) nen service (wahrsch. also xml) is nehm ich halt ein anders view-verzeichnis, denn die scripte und def. auch die meisten helper werden sich zu backend und frontend (beides html-ausgabe) unterscheiden. selbiges bei controllern. ich geb doch (auch trotz acl) nich jedem controller im front die selben functionen wie bspw. dem admin-controller, daher muss ich die doch auch net auf biegen und brechen in das selbe dir knallen oder??!! und wenn beide die selben funktionen haben sind sie eben default.

daher, sei mitr bitte nich böse, versteh ich den link (einfach so mal hingepinselt) net ganz, da es bei meiner frage auch net direkt bzw. ausschließlich um verzeichnisstruktur ging, sondern auch vorrangig um die beschriebene selektion und die vereinigung verschiedener controller aus verschiedenen modulen in einem admin, backend oder wie auch immer.

mach ma bitte nen satz draus!!

lg
some

[Remi]

Ich hab keine Ahnung, warum Dir anderslautende Verzeichnisnamen so wichtig sind, dass Du von der üblichen Konvention unbedingt abweichen möchtest. Ich würde es nicht empfehlen, weil ich es als verlorene Mühe betrachte. Da Du gefragt hattest, ob Dein Ansatz als gut zu bewerten sei dachte ich mir: 'Vielleicht kennt er die von Zend Framework angedachte Struktur nicht?'

Wie gesagt, ich würde mich damit nicht lange aufhalten, sondern auf der vorgegeben Struktur aufsetzen.

Remi

PS: Bitte setze mal Groß-/Kleinschreibung in Deinen Forenbeiträgen ein, damit sie leichter lesbar werden.

[somebody1981]

Ah ok, dann bitte vielmals Entschuldigung für meine etwas forschen Worte und vielen Dank!

Mir ist das bezüglich der Übersichtlichkeit wirklich durchaus lieber auch direkt klar zu unterscheiden. Besonders, da es ja gerade beim Beispiel Admin-Modul schon um durchaus andere Darstellungen in den Views bzw. auch um meist etwas andere Funktionen in den Controllern geht. Und bei den diesbezüglichen Optionen (also soweit ich das gesehen bzw. verstanden habe) mit a) alles in einen Controller und unterschiedliche Actions, b) verschiedene Controller im selben Verzeichnis oder c) verschiedene Controller in verschiedenen Verzeichnissen, war mir c) eben die übersichtlichste. Denn ich möchte keinesfalls ein Admin-Modul o.ä. schreiben in dem alle zu verwendenden Controller eigentlich ganz anderer Module dort definiert sind. Das is für mich definitiv nicht wirklich modular (Ich muss ja bei jedem Install dann dieses Modul updaten, also zumindest in dieses eingreifen).

Es geht mir ja später auch darum, dass z.B. Frontend, Backend, Service/Api ja relativ übersichtliche Ausprägungen der Applikation sein werden, wogegen ich bein den restlichen Modulen die Möglichkeit haben möchte frei installieren und deinstallieren zu können. Somit erleichter es mir das Verwenden von verschiedenen aber dennoch standardisierten Verzeichnissen das schreiben eines Installers und das diesbezügliche Abgrenzen von Subpackages des Moduls, wie eben Admin-Teil, Service-Teil, Front-Teil, etc.. Und ich habe auch diverse Overrides der Views für verschiedene Templates eingebunden, was mir später die Arbeit als Designer vereinfachen soll (also, dass ich auch mal schnell für ein Design auch mal die Aufbereitung der Daten im View ändern kann, ohne jedes mal die eigentliche view.phtml ändern zu müssen). Diesbezüglich isses ja auch wichtig obs ein Admin-Template oder ein Front-Template is, was ich da designe und da kommt mir die Unterscheidung der Verzeichnisse auch zu Gute.

Aber mal anders herum gefragt, da ich ja durchaus sehr lernbegierig bin, gibt es bestimmte Problematiken bei diesartigem Abweichen (da du von verschwendeter Zeit redetest)? Arbeitet ZF mit den Standards schneller oder so? Ober kennst du Probleme die beim Abweichen auftreten? Finde meine Struktur ja eigentlich recht schön, funktioniert bisher auch alles, will ja aber auch nich nach 500.000 Zeilen Code vor den Baum laufen.

Bezüglich der A&W wie ich zwischen den Hauptbereichen der App switche (so mit Defaultmodul, BaseUrl und festlegen des Teils anahand eines in der URL enthaltenen Schlüsselworts, was dann in die BaseUrl einfließt) is das soweit IO oder lässt sich die Abtrennung einzelner Hauptbereiche (wie z.B. zentralisiertem Admin) anders, besser oder simpler lösen?

Vielen Dank schonmal und Liebe Grüße
some

[Remi]

Ich denke wirklich ernsthafte Probleme wird es aufgrund der Flexibilität des Frameworks wohl nicht geben. Man muß halt die Grundlagen studieren, ausprobieren, sich an anderen, bereits mitgelieferten Routen orientieren und keine Scheu davor haben, sich ggf. mit Regex-Ausdrücken zu beschäftigen. Wenn Du das Forum längere Zeit besuchst, wirst Du feststellen, dass diese Voraussetzungen bei einigen Neulingen nicht immer gegeben sind. Die Themen rund um Routen kommen nämlich immer wieder neu hoch.

Wenn Du es noch nicht gelöst hättest und stattdessen erstmal vor dem Einstieg in das Zend Framework stehen würdest, würde ich empfehlen, die Routen erstmal Routen sein zu lassen und die anderen interessanten Herausforderungen, vor denen Zend Framework Neulinge erstmal stehen, anzugehen. Wenn Du es aber soweit schon am Laufen hast, dann nutze es doch so.

Ob es nun ein zentrales Admin-Modul zur Verwaltung aller Module oder pro Modul ein eigenes Admin-Modul geben sollte, hängt sicherlich von der jeweiligen Anwendung ab. Einige Content Management-Systeme bieten eher ein zentrales Admin-Modul an, über das dann alle Plugins (Zusatzmodule) zentral verwaltet werden. Dazu gibt es oftmals eine Plugin-API, die dann jedes Plugin zu unterstützen hat, damit es über das zentrale Admin-Modul verwaltet werden kann. Der Vorteil für den Benutzer ist, dass er sich nicht durch zu viele verschiedene und ggf. unterschiedlich gestaltete Dialoge quälen muß. Die Lösung wirkt dann aus Benutzersicht ggf. "aufgeräumter".

Remi

[somebody1981]

Danke Remi, das beruhigt ersteinmal ;)

Was das Zend_Framework betrifft, so bin ich da tatsächlich ein absoluter Frischling. Ich mein OK, damit in Berührung bin ich schon vor ner ganzen Weile gekommen (hab schon mehrere Sachen mit Magento gemacht), aber so wirklich Applikationen selber entwickeln is schon was besonderes :D

Aber auch wenn ich vorher meist CMS-Jockey war, hab ich da nie alles für gegeben angesehen (Designs schon gar nich und auch der Code sollte immer das machen was ich wollte) und das möchte ich sehr gern beibehalten (natürlich ohne stur drauflos zu proggen).

Wa das Routing betrifft, so finde ich den Router vom ZF da echt wirklich gelungen. Ich musste bisher noch net einmal ne Route wirklich schreiben, da mir das Teil so gefällt. Ich denke das einzige was ich mal machen muss ist Routes zu definieren, wenn ich mit Aliases für Kategorien oder Artikel arbeiten möchte ... aber da bin ich ganz zuversichtlich.

Aber das soll hier keinesfalls nach dicker Hose klingen! Probleme hab ich trotzdem :D Diese gehen aber im Moment eher in Richtung Struktur und Architektur (z.B. is mir der optimale Layer-Aufbau meiner Applikation noch unschlüssig ... so das ich wirklich alles Modular halte) und nich in Richtung technischem Einsatz vom ZF, da is das meiste ja supie dokumentiert und vor API-Dokumenten scheu ich mich zum Glück auch net, wenns ma net in der Programmers-Reference is ;)

Was das Admin-Modul betrifft, so bin auch ich eher der zentrale Typ, nich wirklich wegen der Kunden-Sicht, eher weil ich es für mich präferiere alles an einem Ort zu haben und so auch immer gleich zu sehen ob sich ein neuer Teil ins Gesamte einfügt. Und ich stehe eben wirklich enorm auf Modularisierung. Bei der Technik dafür hab ich von nem eigenen Plugin-System ?* la Observer-Pattern und Co. bisher noch abgesehen. Aber genau da hab ich jetzt das gefühl dass ich einiges nochmal dahingehend umschreiben muss, weils dann hintenraus leichter wird.

Aber naja, ich will ja lernen, da muss man auch manches mehrmals machen. Und zu erfahren wie es nicht geht oder net optimal is, is ja auch was ... auch wenns nervt :D

lg
some