ND_CMS : mes réflexions concernant l'arborescence
Par Nicolas Desaleux. mercredi, octobre 14 2009, 19:40. ND_CMS Conception web ND_CMS PHP Zend Framework | Lien permanent.
ND_CMS doit être, pour moi, une base me permettant de développer facilement un site web.
Je pars du principe que j’utiliserai le Zend Framework pour le réaliser, Cependant l’architecture proposée ne me semble pas la plus pertinente.
Proposition d’arborescence
Libraries
Zend
ND
Htdocs // Seul répertoire accessible par le Web
index.php
.htaccess // potentiellement externalisée dans la configuration apache
Application // Répertoire ou sont stockées les informations propres aux applications
MonAppli1
Config // fichiers de configuration propre à l'application=
Cache // Répertoire parent des différents caches de l'application
Db
Page
Datas // Données propres à l'application (c'est le SEUL répertoire accessible par FTP pour le client)
Layout // fichiers concernant la présentation
Js
Css
Files
I18n // Fichiers concernant l'internationalisation propre à l'application
Session // Répertoire permettant de stocker les informations de session, si les sessions ne sont pas gérer en base de données
Log // Répertoire ou se situe les logs de l'application
MonAppli2
Config
Cache
Db
Page
Datas
Js
Css
Files
I18n
Session
Common // Stockage des informations communes à toutes les applications (les données peuvent être surchargées par les données applications)
I18n // fichiers d'internationalisation transversaux message d'erreur applicatifs (ex:Erreur 404 ou des validateurs de formulaire)
JS // répertoire où sera stocké le(s) framework(s) JS utilisé(s) probablement jquery
CSS // répertoire où sera stocké le(s) framework(s) CSS utilisé(s) probablement blueprint
Modules // Répertoire où seront stockés les différents modules
Module
Controllers
Views
Scripts
Helpers
Data
I18n
Db
Js
Models
DbTable
Mapper
Forms
Services
Cette architecture permet
- de n’avoir qu’un point d’entré Web non corruptible par le client
- de compartimenter les bibliothèques, les modules, les données d’applications
* les données d'applications sont compartimentées afin d'empêcher au mieux les interactions entres elles * seul l'accès au répertoire Data est faisable via FTP (enfin selon configuration de celui-ci), les autres dossiers n'étant modifiable que par les interfaces web dédiés hors cache
L’inconvénient de cette architecture est que la mise à jour d’un module ne doit pas agir sur la BDD ou alors cette modification de la BDD ne doit pas être bloquant pour l’utilisation du module
Et vous, comment feriez vous ? Que pensez vous d’une telle architecture ?