Présentation de l'arborescence du CMS en image

L'arborescence des fichiers et dossiers pour laquelle j'ai opté dans la conception du CMS avec Zend Framework, est un peu particulière, mais dans la logique elle prend tout son sens. Je vous explique ...
Voici avant de commencer, une représentation de l'architecture en image, car je pense que cela en dira plus long qu'un texte :
arborescence CMS Toute l'architecture n'y est pas représentée, car il faut que j'avance un peu plus pour vous en faire part. Mais vous avez déjà une bonne idée de quoi il en retourne.

Séparer le développement répétitif du ponctuel

Je n'ai pas voulu réinventer la structure de base, proposé par Zend Framework. Mais le but est de séparer au maximum les actions de développement répétitif du ponctuel afin de gagner du temps lors du développement d'un module supplémentaire. Et cela, aussi bien pour un professionnel qu'un utilisateur particulier.

Pour illustrer un peu mieux mon exemple de la séparation du répétitif et du ponctuel, on peut considérer le développement redondant, comme une partie de la programmation général à toutes les applications.

J'espère ne pas vous avoir déjà perdu dans ces premiers détails ! La suite n'en est pas plus facile à expliquer. Je vais donc vous la détailler l'arborescence de haut en bas.

Présentation de l'architecture des fichiers avec Zend

On retrouve l'éternel dossier "Application" qui englobe pas mal de choses, comme le dossier "ajax" où sont regroupés les scripts permettant de créer des actions interactives et répétitives dans les modules. Le dossier "data", quant à lui, est prévu pour l'ensemble des fichiers de configurations, qui sont au format INI.

A partir de ce moment, il y a un peu de changement. Le dossier "languages" est divisé en modules afin de pouvoir si retrouver pour changer un fichier de traduction. Ensuite, c'est au choix, soit vous préférez créer un fichier avec le nom du module et vous y mettez tout la traduction, soit vous créez un fichier par parties. Dans l'exemple en image, j'ai pris la partie de connexion (login) et la page d'accueil de l'administrateur.

Et oui le module administrateur ne se nomme pas administrator, admin, ou administration, mais manager ! Un choix qui change un peu, car pour ma part, je teste régulièrement les sites en cherchant leur panneau de contrôle. Ce qui est le plus désolant, c'est que certains sites ont le même login et mot de passe comme par exemple... Heu... ADMIN. Non, non, ce n'est pas des sites de démonstration, mais je ne nommerais personne ;)

Le dossier "modules" vient en ensuite. Sur le principe général, on retrouve un sous-dossier par module. Manager, Public (le module par défaut), ... Et d'autres encore, mais pour plus tard.

Et maintenant, vous l'aurez remarqué, il y a un peu de chamboulement dans l'organisation.

Et oui, j'ai pété un câble ! Mais vous allez voir... ;)

Actuellement, deux dossiers :

Le dossier "extends" regroupe tous les contrôleurs de Zend Framework ainsi que leurs vues respectives. Prenons pour exemple, le contrôleur index de Zend. Dans notre cas, le contrôleur "indexController.php" sera placé dans le dossier "index". Ensuite, plus aucun moyen de se perdre. Il y a le dossier "views" avec ses sous-répertoires "scripts", "helpers" et "filters". A la seule différence, c'est que les vues sont uniquement celles qui font référence à une action du contrôleur.

Le dossier "views" à la même structure que celui du contrôleur décrit précédemment. Encore une fois, c'est pour séparer les scripts répétitifs du ponctuel dans l'ensemble du module en question que ce dossier a été créé.

Pourquoi avoir adopté pour une telle structure dans les modules ?

C'est dans plusieurs buts. Le premier, je trouve plus facile, pour faire des modifications, d'avoir dans le même dossier l'ensemble des éléments (un avis que je partage avec certains d'entre vous et je vous remercie de vos remarques). Ensuite, l'objectif est de rendre modulaire le CMS, afin de pouvoir ajouter ou supprimer des parties au gestionnaire de contenu. Pour terminer, je prévois un système "overrides" au niveau des vues afin de ne pas faire de modification directement dans les modules et ainsi éviter toutes erreurs de programmation irréversibles. Mais ce sujet fera l'objet d'un autre billet.

Je passerais plus rapidement sur les dossiers "Include" et "Core" qui sont des librairies pour le fonctionnement du projet. Je pense les présenter plus en détail dans un autre article car celui-ci est déjà bien long.

Pour finir ce sujet, il reste le dossier "Template" qui est structuré en sous-dossiers faisant référence aux modules. Le dossier suivant (default) représente de template par défaut utilisé par l'application avec, dedans le système "overrides".

Une partie de l'arborescence est expliqué ici, mais il me reste encore quelques petites particularités à vous faire découvrir prochainement. Ce billet était aussi fait dans but de montrer un nouveau type organisation dans les dossiers. Allez, à vos claviers (si vous avez des remarques), je retourne sur mes bugs, encore et encore... ;)