| Date | Reviewed | Purpose | Discipline | Example |
|---|---|---|---|---|
| 2018.06 | 2021.12 | Pedagogy | PHP | PHP-MVC |
Le but n'est pas de fournir publiquement un modèle ou un template intégrable, mais bien de montrer comment développer quelque chose de similaire en se servant de ce projet comme exemple de départ. Il n'y aura pas de versions ultérieures, ce projet ne va pas évoluer – sauf corrections bugs, erreurs, coquilles laissés par mégarde.
Exemple de développement d'un site web en vanilla PHP à travers l'architecture Model-View-Controller et le paradigme Orienté Objet.
- Apprendre la résolution d'un système de routage en PHP
- Découvrir l'architecture Model-View-Controller et la Programmation Orientée Objets
- Observer une structure et une organisation de fichiers pertinentes
Le thème employé est celui des Design Patterns. Cette application étant une simple démonstration de développement, elle n'a pas pour vocation de présenter un contenu absolument complet, et peut se montrer très approximative sur certains points. Les sources principales – et uniques – des informations présentées ne sont autres que la page Wikibooks : Patrons de Conception et la page Wikipédia : Patron de conception.
Sauf un quelconque défaut laissé par mégarde, ce projet ne doit pas évoluer vers une modélisation plus avancée. Il constitue une ressource pédagogique de base destinée à l'apprentissage de concepts parfois obscurs pour des néophytes.
Ce projet n'est utilisable que dans un cadre d'apprentissage individuel et privé. Il ne convient pas pour une utilisation publique ou professionnelle.
Certaines images employées dans ce projet – sauf celles listées dans "Exceptions" – sont soumises aux droits d'auteur et protégées par la Sofam – auteure n° 72/55. Aucune reproduction, communication publique, réutilisation partielle ou entière des images n'est autorisée.
- les logos des technologies employés sur la page Informations.
Le projet requiert quelques éléments pour fonctionner et une configuration minimum.
- Un serveur Web local tel que Wamp – ou Xampp, ou Mamp, ou Easy-PHP, etc.
- PHP > 7.1
- Un Virtual Host, à mettre en place selon la procédure décrite dans la documentation du Server Web local. Le nom du Virtual Host ou du dossier n'a aucune importance puisque seul le path de chaque requête entre en jeu.
- Un système de gestion de base de données en SQL tel que MySQL – ou MariaDB, ou PostgreSQL, etc. Lequel est généralement inclu avec le pack de serveur web local.
Ce fichier doit être placé à la racine du dossier de ce projet. Le code ci-dessous est suffisemment efficace pour ce type de projet.
# Active la ré-écriture
RewriteEngine on
# Éviter les requêtes des ressources embarquées (où se trouvent les .css, .js, .jpg, etc.)
RewriteCond %{REQUEST_URI} !^/(public|assets)/.*$
# Éviter les requêtes de fichiers clairement ciblés et résolvables
RewriteCond %{REQUEST_FILENAME} !-f
# Rediriger les requêtes vers le point d'entrée de l'application
RewriteRule . /index.php [QSA,L]
Le fichier phpmvc_db.sql est à charger dans un système de gestion de bases de données en SQL. Ensuite les constantes de connexion doivent être mises à jour en fonction des paramètres environnementaux dans le fichier core/constants.php.
const DATABASE = [
'pilot' => 'mysql',
'host' => '127.0.0.1',
'port' => '3306',
'dbname' => 'phpmvc',
'charset' => 'utf8mb4',
'user' => 'root',
'password' => ''
];Chaque partie observe une structure spécifique. Laquelle est utile à découvrir pour mieux comprendre le projet et sa résolution.
- Design Patterns ::
/ - Gang Of Four ::
/gang-of-four - Patrons ::
/patron- Model-View-Controller ::
./model-view-controller - Model-View-VueModel ::
./model-view-viewmodel - Model-View-Presentation ::
./model-view-presentation
- Model-View-Controller ::
- Informations ::
/info
Il n'y a aucune librairie tierce dans ce projet.
assets/images, icônes, logos, etc.core/code source métier de l'applicationError/Controller/View/Error.php
GangOfFour/Controller/View/GangOfFour.php
Home/Controller/View/Home.php
Info/Controller/View/Home.php
Patron/Controller/Model/View/Patron.php
Template/fichiers communs de vueLayout.phpMenu.php
constants.phpfichiers sur lesquels le code source métier s'appuie
lib/librairies de servicesphpmvc/classes de services propres à l'application elle-même
public/code source frontendcss/js/
_manifest.jsonen guise d'exemple (optionnel), à préfixer avec le nom de l'application.htaccessconfiguration des requêtes entrantesindex.phppoint d'entrée de l'applicationunavailable.phpdestination en cas d'erreur de programme
Cet exemple répond à un fonctionnement basique de traitements Back-End en PHP. Le principe est donc de capter des requêtes, d'analyser leurs destinations, d'exploiter le traitement associé, et de construire une réponse.
Dans cet exemple, certains traitements ont été volontairement écarté sans quoi ce projet serait beaucoup trop volumineux. Entre autres, les traitements suivants :
- Les requêtes d'insertions, de modifications ou de suppressions de données
- Les requêtes désynchronisées – AJAX
- Les autres formats de réponse – tels que le JSon ou l'XML
- L'exploitation des parties scheme, user, password, host, query et fragment d'une URL standard
- Le contrôle de formulaire (aucun n'est d'ailleurs présent)
En Orienté objet, tout est objet. Et selon les principes de l'architecture MVC, un contrôleur capte une "demande" utilisateur, opère un traitement sur le modèle – si lieu – puis notifie la vue qui est alors "mise à jour".
Pour une application Web plus conséquente, quelque éléments additionnels entrent en jeu.
Tous ces objets – ces classes – doivent être classés convenablement. Il y a donc :
- un répertoire
core/, lequel contient les sous-répertoires "métiers", avec à chaque fois un dossierController, un dossierView, et le cas échéant, un dossierModel, comme préconisés par l'architecture MVC ; - un répertoire
lib/phpmvc, lequel contient les classes générales, celles qui sont utilisées à chaque requêtes – pratiquement.
Le fichier .htaccess redirige chaque requête vers une stratégie principale – cf. catégorie “Gang of Four” › Strategie › Comportement. Cette stratégie principale est mise en place par la classe phpmvc\Process qui s'occupe de trouver le contrôleur approprié en mettant en relation la requête et les managers répartis à la racine de chaque "métier".
Ces managers font office de router. Ils consituent une sorte de "sous-stratégie" sous forme d'objet composite – cf. catégorie “Gang of Four” › Structure › Objet Composite – régit par un objet parent, la classe phpmvc\Manager. Chacun d'eux s'utilise donc de la même manière par la stratégie principale.
Chaque section "métier" organise ses fichiers en fonction de leur tâche. Les fichiers de Vues ne contiennent que du HTML avec des espaces variables réservés aux données. Les contrôleurs, eux, sont également des "objets composites" qui fonctionnent tous de la même manière puisqu'ils sont régit par la classe phpmvc/Controller. Un contrôleur fait office "d'observateur" – cf. catégorie “Gang of Four” › Comportement › Observateur –, il en faut donc un pour chaque requête.
Dans le cas où interviennent des données issues de la base de données, une classe de "modèle métier" sert à encapsuler les requêtes SQL et la connexion à la base de données en exploitant la classe générale phpmvc/Repository. Dans cet exemple, une classe d'entité est également prévue pour représenter les champs de la base de données sous formes de propriétés d'objets – technique du PDO::FETCH_CLASS dans les Fetch Modes.
En définitive, chaque requête abouti sur un contrôleur qui charge une vue, le layout de la page, et construit une réponse à renvoyer au client. L'erreur 400 - Bad Request et l'erreur 404 - Not found fonctionnent de la même manière que les autres requêtes. Dans le cas où aucune réponse ne pourrait être construite, c'est une redirection vers le fichier statique unavailable.php qui prend le relait. Cela signifierait qu'une erreur se cache dans la logique du traitement, et qu'il faut corriger le code source.
(R.A.S)