FramElem : mon framework PHP pas à pas - 1. Les principes

Un billet blog de CinéPhil

Avant-propos
Déçu (voire limite désappointé façon Zorg dans « Le 5ème élément »  ) par les frameworks que j’ai tenté d’essayer d’adopter (c’est vous dire si les « grands » frameworks m’ont déçu), j’ai décidé de me lancer dans la réalisation de mon propre framework afin de :
- comprendre et maîtriser ce qu’il fait ;
- pouvoir déboguer et améliorer le code de celui-ci au gré de mes besoins ;
- essayer d’éviter le principal défaut des « grands frameworks » : le chargement de dizaines de classes rien que pour afficher une page simple.

La série de billets qui commence ici décrit ma démarche dans la réalisation de ce framework que j’ai nommé « FramElem » et qui se veut un « framework élémentaire » .

Mise à jour du 25/04/2024 : Quasiment 5 ans que j'ai commencé cette série de billets et ce framework ! La vie professionnelle et personnelle étant ce qu'elle est, je n'ai jamais pu terminer ce projet ambitieux. Ma carrière de salarié étant terminée depuis début avril 2024, je décide aujourd'hui de m'y remettre et de tout reprendre, en espérant cette fois atteindre l'objectif. Par contre, ce sera sous la forme d'un (long) article, ou de plusieurs.

1. Principes généraux
1.1. Les fonctionnalités du framework
Tout site web un peu évolué a besoin :

• d’une page d’accueil ;
• d’une connexion utilisateur ;
• d’une gestion des droits d’accès aux fonctions de l’application ;
• d’un menu principal.

Côté machinerie, partie invisible pour le visiteur lambda, la gestion des données est généralement faite à l’aide d’une base de données relationnelle.
Pour se faire, l’administrateur du site, ses éventuels modérateurs ou autres gestionnaires, aux droits souvent un peu moins complets que l’administrateur, ont besoin d’une interface conviviale pour accéder et gérer les données du site. On appelle ça, généralement, le « back-office » , en opposition au « front-office » qui est la partie visible du site par ses visiteurs et utilisateurs inscrits.

Le back-office doit comprendre :

• la gestion des données de référence (catégories, groupes, types, familles...) ;
• la gestion des utilisateurs, de leur appartenance à des catégories ou groupes ;
• la gestion des droits d’accès ;
• la gestion des menus.

C’est tout pour le moment. D’autres fonctionnalités devront pouvoir être ajoutées ultérieurement sans remettre en cause trop profondément ce qui a déjà été développé.

1.2. Principes de développement
Le développement sera fait en programmation orientée objet (POO) selon l’architecture Modèle, Vue, Contrôleur (MVC) et en langage PHP.

La base de données sera modélisée à partir d’un Modèle Conceptuel de Données (MCD) de la méthode Merise qui reste, à mon avis, le meilleur outil de conception d’une base de données relationnelle.
Les données seront accessibles en lecture via des vues et en écriture via des procédures SQL, ce qui permet de garantir la cohérence des données, contrôlée par le Système de Gestion de Bases de Données (SGBD). On appelle ça le développement en base de données épaisse.

Les erreurs et exceptions seront capturées et transcrites en langage clair à l’utilisateur du site.

2. La base de données
2.1. Principes de modélisation
La base de données comprendra au moins trois schémas :

• Le référentiel, appelé à contenir les données de référence (pays, territoires, villes, civilités...) utilisables par toute application ;
• Le schéma général, destiné à accueillir les données propres à l’application.
• Le schéma d’administration, destiné à accueillir les métadonnées sur la base de données (description des éléments, historique des évolutions...) ;

Les MCD seront réalisés à l’aide d’un logiciel de modélisation, afin de bénéficier de la génération automatique du MLD puis du script SQL de création des tables avec leurs index, clés étrangères et autres contraintes.

Pour les débutants, il est fortement conseillé de commencer par écrire des règles de gestion des données.

2.2. Norme de nommage
J’applique une norme de nommage inspirée de celle de SQLPro. Je recommande cette bonne pratique, quelle que soit votre manière de nommer les éléments de la base de données, parce que ça rend plus facile ensuite l’écriture des requêtes SQL.

3. Architecture logicielle
Fichiers bien rangés sont faciles à retrouver !

Une protection des dossiers de fichiers du site sera mise en place afin d’éviter qu’un pirate vienne bidouiller vos fichiers PHP ou accède au compte et mot de passe d’accès à la base de données.

3.1. Racine du site
Le dossier racine du site portera le nom du site. Comme il s’agit ici de construire « FramElem » , le dossier racine portera donc le nom de « framelem ». Élémentaire, mon cher Watson !
Ainsi, une fois le framework terminé et prêt à être utilisé pour faire un vrai site, il suffira de copier l’ensemble du dossier « framelem » et de lui donner le nom du site à fabriquer.

Dans ce dossier racine, on trouvera les fichiers utiles au site suivants :

• "index.php" qui sera la porte d’entrée unique sur le site ;
• ".htaccess" qui sert à traduire les URL signifiantes en URL paramétrées compréhensibles par le programme.

Et c’est tout !

3.2. Arborescence des sous dossiers du site
Commençons simplement, on ajoutera des sous-dossiers au gré des besoins lors de la construction du framework. Il faudra aussi des sous-dossiers pour le site à réaliser, mais ça viendra plus tard.

Le premier niveau de sous-dossiers n’en comprend que trois :

• « application », qui contiendra tous les programmes applicatifs en PHP ;
• « public », qui contiendra tous les fichiers qui peuvent rester publics parce que téléchargés par le client web, tels que les feuilles de style CSS, les programmes JavaScript, les images...
• « vendor », qui contiendra tous les programmes du framework FramElem et qui consituent le moteur des futures applications.

Décrivons maintenant le deuxième niveau de sous-dossiers en entrant dans le dossier « public ». On y créera, pour commencer, les sous-dossiers suivants :

• « css » , qui contiendra donc toutes nos feuilles de styles ;
• « images », qui accueillera toutes les images enjolivant les pages du site ;
• « js » qui contiendra tous les fichiers de programmes JavaScript.

Quant au dossier « application », il comprendra, pour commencer, les sous-dossiers suivants :

• « config », destiné à recevoir les fichiers de configuration ;
• « controllers », qui contiendra les programmes de contrôle utilisables par n’importe quelle partie du site ;
• « models », qui contiendra les classes PHP de modèle de données qui communiquent avec la base de données ;
• « modules » qui contiendra les futurs modules applicatifs du site, de back-office et de front-office ;
• « views » qui contiendra les vues, c’est-à-dire les fichiers construisant les écrans principaux ou morceaux d’écrans utilisables par n’importe quelle partie du site.

Le dossier « vendor » comprendra pour commencer l'arborescence suivante :

• logicielem
  
  • framelem (sous-dossier de "logicielem"
  
  

"logicielem" est le nom de ma micro-entreprise et "framelem" est le nom du framework. Le dossier vendor sera susceptible d'accueillir des outils externes, non développés par moi.

En troisième niveau, dans le dossier « modules », il y aura autant de sous-dossiers que de modules applicatifs. Le premier de ces modules, directement créé avec le framework, sera le module « Accueil ».

Dans chaque dossier de module, on créera en quatrième niveau contenant, de nouveau, les deux dossiers suivants :

• « controllers », destiné à accueillir les programmes de contrôle spécifiques au module ;
• « views », destiné à accueillir les vues spécifiques au module.

Notre première arborescence ressemble donc à ça :


4. Règles de codage
Un code commenté est un code lisible et plus facile à comprendre et à déboguer

4.1. Informations générales sur les fichiers
Tous les fichiers de programmes du site (en PHP, CSS, JavaScript) comprendront un en-tête donnant les informations suivantes :

• une description succincte du rôle du fichier.
• le chemin complet depuis le dossier racine et le nom du fichier ;
• le nom du premier auteur du fichier ;
• la version en vigueur du fichier avec sa date, l’auteur de la version et l’explication succincte du changement de version.

L’en-tête sera immédiatement suivie d’une rubrique « Historique » dans laquelle seront copiées au fur et à mesure les différentes version du fichier.

Les vues, procédures, triggers et fonctions SQL comprendront les mêmes informations, plus l’indication des tables et/ou vues utilisées par le programme SQL.

4.2. Commentaires
Le code sera commenté autant que nécessaire à la compréhension de celui-ci. Notamment :

• les méthodes de classes et autres fonctions seront précédées d’un en-tête donnant le rôle de la fonction, les paramètres d’entrée et de sortie ;
• les conditions (if) seront immédiatement suivies d’une explication sur le rôle de la condition ;
• idem pour les structures de boucles (foreach...) ;

À suivre : La création du projet et la structure générale des pages du site.