Cet article fait suite à la Partie 2

Avant de commencer à compliquer le bouzin, et surtout, avant de commencer l'url-rewriting, je me suis dit que présenter tout de suite l'objectif final permettrait sûrement de gagner beaucoup de temps. Pour cela, je me suis replongé dans l'UML2, mais j'avoue que je galère, c'est pas trop mon truc les blocks (je préférais les patates).

Schema UML de Framy

Alors, étudions un peu ça. Tout d'abord, il ne faut surtout pas avoir peur !

Le commencement, c'est la méthode yBoot::launch() qui sera appelée par exemple dans l'index.php Cette méthode static crée 2 objets :

  • $resquest (yRequest)
  • $response (yResponse)

La classe yRequest contient les attributs et méthodes nécessaires à l'analyse de la requête de l'utilisateur. C'est elle qui va déterminer le couple contrôleur/action à utiliser à travers les différents classes de traitement de l'URL disponibles.
La classe yResponse contient simplement la réponse que Framy enverra au navigateur, ce qui comprend entête HTTP et contenu. On crée ces classes dans le boot pour

  • Déterminer le couple contrôleur/action ainsi que les paramètres.
  • Valider la requête et si besoin, envoyer une erreur 404
  • Charger la configuration globale de Framy (que nous ne verrons pas du tout ici)
  • Lancer l'application (ie : Instancier le contrôleur et lancer l'action)

Ensuite, l'ensemble des pouvoirs est transmis au contrôleur (applicationController est un contrôleur arbitraire pour servir d'exemple). N'oublions pas que le contrôleur hérite de la classe abstraite yController, qui possède tout ce dont on a besoin, et qui va récupérer au passage l'objet $request et l'objet $response (regardez donc le constructeur de yController).

Voila, maintenant que les choses sont claires, nous pouvons commencer à travailler sur chacune des parties. A commencer bientôt par l'url-rewriting.

Allez à la 4ième partie