Comme tous les frameworks PHP, FrameBeurk est composé d’un ensemble de scripts qui sont hébergés sur une machine serveur distante (*), sur laquelle est opérationnel un programme serveur http (tel que Apache), équipé d’un module d’interprétation du PHP.
Lorsque le navigateur Internet de l’utilisateur envoie une requête au serveur http, celui-ci exécute les scripts PHP déterminés. Ceux-ci génèrent du code HTML (ou CSS, ou Javascript, ou RSS…) qui est renvoyé au navigateur qui interprète ce code pour afficher une page, ou influer sur l’affichage de la page existante.
(*) : ou installés éventuellement sur la machine de l’utilisateur ou du développeur comme dans le cas de l’utilisation de LAMP/WAMP (pour Linux-Apache-MySQL-PHP, Windows-Apache...)
Certaines actions de l’utilisateur dans son navigateur Internet entrainent l’envoi d’une requête http vers le serveur. On nomme transaction ce qui se déroule entre une telle action et la prise en compte de la réponse du serveur par le navigateur, et plus particulièrement les traitements qui ont lieu sur le serveur entre l’arrivée de la requête et l’envoi de la réponse.
L’échange de données entre le navigateur internet de l’utilisateur et le serveur se déroule en mode « pseudo-conversationnel ». C’est-à-dire que du point de vue de l’utilisateur, il n’y a pas de discontinuité entre 2 transactions. Côté serveur par contre, l’exécution des scripts est interrompue à l’envoi de la réponse et ceux-ci sont retirés de la mémoire. La discontinuité est donc complète côté serveur.
Pour rétablir la cohérence du dialogue –c’est-à-dire de l’enchainement des transactions, les valeurs des variables qui doivent être rétablies lors de la transaction suivante sont stockée en session : PHP les sauvegardes en dehors du serveur (pour une durée limitée et paramétrable, par exemple 30 minutes).
Les dialogues de plusieurs utilisateurs navigants en parallèle sur le même site sont totalement indépendants.
Framebeurk est modulaire, paramétrable et extensible. Les fonctionnalités et rendus propres au site, et communs à tous les utilisateurs, sont définis par des paramètres qui constituent la configuration de ce site. Afin d’améliorer les performances du framework, la configuration est déterminée lors de la première transaction de l’utilisateur puis stockée en session PHP.
S’agissant d’un framework applicatif, les actions envoyées au serveur et qui sont (habituellement) déclenchées par l’utilisateur (par exemple lorsque celui-ci clique sur un lien ou un bouton) sont de deux sortes :
Dans FrameBeurk, une transaction sera constituée d’une action Maj et d’une action Vue. Si une action Maj est demandée, elle sera toujours exécutée en premier, car elle peut avoir un impact sur les informations restituées dans la Vue.
C’est le navigateur Internet de l’utilisateur qui envoie au serveur les informations concernant la Maj et/ou la Vue à exécuter, par les paramètres de la requête http.
La requête peut aussi préciser une Vue d’erreur à restituer à la place de la Vue normale, en cas d’erreur lors de la Maj.
Comme exposé en début de document, ce framework propose aux développeurs d’effectuer une approche des besoins fonctionnels métier différente de l’Analyse Orientée Objet, avec une implémentation (séquentielle ou procédurale) plus simple que la POO (voir chapitre 9). Pour rester clairement indépendant du paradigme Objet, les équivalents-objets seront nommés Entités.
Essayons cette définition : Une Entité est la projection sur l’interface applicative d’un objet métier, élémentaire ou complexe, qui ne sera jamais défini de manière nucléaire contrairement à la POO. L’Entité portera les actions de type Maj et/ou Vue accessibles aux utilisateurs.
Les Entités sont regroupées en ensembles fonctionnellement cohérents nommés Modules.
Les modules peuvent naturellement présenter des dépendances entre eux. L’exemple trivial est celui de l’appel dans un script du module B d’une fonction PHP définie par le module A.
Si le module A déclare « function A_fonct() {…} » et le module B implémente l’appel à cette fonction « $maVar = A_fonct() ; », le module B est dépendant du module A et ne pourra pas s’exécuter sans lui.
La documentation du module B doit explicitement signaler cette dépendance statique.
Le langage PHP permet de stocker le nom d’une fonction dans une variable. L’utilisation de cette possibilité permet d’appeler une fonction déclarée dans un autre module sans en être définitivement dépendant.
Si le code du module B utilise un alias (c-à-d une variable) pour appeler une fonction externe au module et que le module A implémente cette fonction, la configuration du site (*) doit associer l’alias utilisé dans le module B à la fonction déclarée dans A. On nomme Tissage cette mise en relation des modules.
La documentation du module B doit spécifier quels sont les alias à valoriser.
(*) : Le tissage peut être directement configuré au niveau du module A si celui-ci est lui-même dépendant du module B.
Pour tenter de résumer simplement, la page HTML affichée par le navigateur est un ensemble de boites nommées « div », imbriquées ou juxtaposées, qui contiennent les informations métier. L’agencement des divs entre elles (et leurs rendus) est fixé par la feuille de style (fichier .css) déclarée en début de page HTML et envoyée par le serveur au navigateur.
La mise en page (Layout en Anglais) est en règle générale très stable d’une page à l’autre d’un même site Internet et il est donc intéressant de faciliter la gestion et les traitements qui lui sont associés. Ce framework propose de gérer en configuration la mise en page avec les éléments suivants :
Le patron définit les principales parties de la page où le contenu sera inséré dynamiquement par un contrôleur (voir plus loin pour cette notion).
Le contenu de chaque Div est déclarées en configuration. Typiquement, il s'agit d'un libellé, d'une variable ou d'un fichier PHP à insérer. Lorsqu'il traite une partie du patron, le contrôleur y insère le contenu des Divs dont le nom commence par celui de la partie traitée. Exemple : Si le patron possède une div nommée 'Partie1' dans laquelle le contrôleur est appelé et que les Divs 'Partie1a' et 'Partie1b' sont décrites dans la configuration, elles seront déclarées dans 'Partie1' et leur contenu y sera inséré.
Un Layout est l’association d’un Patron avec des déclarations de Divs. On peut définir plusieurs Layouts, mais un seul est utilisé à la fois.
Afin de garantir les meilleures performances au site, les échanges avec le serveur sont réduits au minimum en termes de nombres et de volumes :
Pour cette dernière fonctionnalité, des fonctions Javascript spécifiques au framework implémentent la technique Ajax (Asynchronous Javascript and XML) selon une modalité non obstrusive (les liens continuent de fonctionner sans Javascript, mais rechargent la page complète).
(*) : Le rafraichissement des CSS et JS par le navigateur sera forcé par le changement du numéro de version du site sur le serveur.
(Cette fonctionnalité reste en projet. Rien n’a encore été développé.)
Lorsqu’une vue est rafraichie, sans que la page entière le soit, il peut arriver que le contenu de vues non rafraichies ne soit plus à jour (typiquement si une Maj a été effectuée). Pour demander le rafraichissement de ces vues après la réponse du serveur, une gestion évènementielle est mise en place entre le serveur et le navigateur de l’utilisateur.
