PHPAML

Documentation · Chapitre 02

Une plateforme,
quatre structures.

PHPAML conserve les principes utiles, puis retire les dossiers qui n’ont aucun rôle dans le type de projet choisi.

Aucun vocabulaire technique préalable n’est nécessaire. Chaque nouveau mot est expliqué avant d’être utilisé.

Choisissez selon la sortie attendue.

Ne choisissez pas une variante parce qu’elle paraît plus moderne. Demandez d’abord : qui utilisera le programme et quelle réponse doit-il recevoir ? Une page HTML, une interface réactive, des données JSON ou du texte dans un terminal conduisent naturellement à quatre structures différentes.

Ce ne sont pas quatre langages différents.

Dans les quatre cas, vous écrivez du PHP. Ce qui change est la manière dont le programme est utilisé. Un visiteur peut recevoir une page complète, manipuler une interface réactive, une autre application peut demander des données, ou une personne peut lancer une commande dans le terminal.

Application classique

Elle reçoit une requête HTTP, utilise routes et contrôleurs, puis rend généralement une vue PHP sur le serveur.

phpaml — zsh
src/controllers/
src/models/
src/middleware/
src/routes/WebApp.php
src/views/
public/index.php

AML View

Elle conserve le serveur PHPAML, mais ses pages et composants déclaratifs vivent sous src/views. Engine prend ensuite en charge les interactions frontend compilées.

phpaml — zsh
src/views/pages/
src/views/components/
src/views/layouts/
src/views/stylesheets/
src/routes/WebApp.php

API

Elle utilise HTTP, routes, contrôleurs et données, mais ne contient pas de couche de vues. Sa représentation finale est généralement JSON.

phpaml — zsh
src/controllers/
src/requests/
src/resources/
src/repositories/
src/routes/
public/index.php

Console

Elle n’a ni navigateur, ni requête HTTP, ni route. Program::main() reçoit les arguments du terminal et retourne un code de sortie.

phpaml — zsh
src/Program.php
src/
tests/
phpaml.json

Le même catalogue, quatre usages.

Site de bibliothèque rendu sur le serveuraml create
Recherche réactive sans rechargement manuelaml create-view
Catalogue consommé par une application mobileaml create-api
Import de 500 livres depuis un fichieraml create-console

Comparaison rapide.

ProjetUtilisé depuisRésultat principalIdéal pour
ClassiqueNavigateurHTMLSites et formulaires rendus sur le serveur
ViewNavigateurInterface réactiveTableaux de bord et applications interactives
APIMobile, site ou serviceJSONPartager des données entre applications
ConsoleTerminalTexte et code de sortieAutomatisation, apprentissage et tâches planifiées

VÉRIFIEZ VOTRE COMPRÉHENSION

Une API doit-elle obligatoirement avoir une vue ?

Afficher la réponse

Non. Sa représentation finale est généralement JSON. Elle conserve routes, contrôleurs et données, mais n’a pas besoin d’une couche HTML.

À VOUS DE JOUER

Choisissez une variante pour : un tableau de bord interactif, une commande de sauvegarde nocturne, un service mobile et un petit site institutionnel.

Voir un indice

View, Console, API, puis Classique.

QUESTIONS DE DÉBUTANT

Vous vous demandez peut-être…

Puis-je ajouter Data à ces projets ?

Oui. Le module Data peut être ajouté lorsqu’un projet doit stocker et retrouver des informations.

Une application View possède-t-elle encore un serveur ?

Oui. PHPAML et Engine collaborent pour produire l’interface et ses interactions.

Puis-je commencer simplement puis ajouter des modules ?

Oui. Le type de départ donne une structure adaptée; les modules nécessaires peuvent ensuite être installés.

EN RÉSUMÉ

Ce qu’il faut retenir

  • Classique rend des pages sur le serveur.
  • View ajoute une interface déclarative réactive.
  • API répond sans vue, généralement en JSON.
  • Console exécute du PHP sans serveur HTTP.