FrameBeurk

FrameBeurk a été imaginé en prenant pour modèle initial la cinématique des écrans de l'AGL Pacbase (transactions 3270 dans le monde Mainframe IBM). Très schématiquement, un écran Pacbase est un programme qui se compose de 2 parties :

• La première effectue les mises à jour (le cas échéant) dans la base de données. Cette partie n'est exécutée que si l'utilisateur se trouvait déjà sur le même écran.
• La seconde renvoie les informations à afficher par le terminal (la map), qui seront éventuellement modifiées à la prochaine éxécution du programme (dans la 1ère partie).

Entre ces 2 parties, un aiguillage permet de renvoyer l'utilisateur sur l'affichage d'un autre écran, selon les informations qu'il a saisies ou la touche fonction qu'il a pressée.

Le portage de cette cinématique dans le framework PHP FrameBeurk donne un point d'entrée unique : Le classique fichier index.php, qui va successivement exécuter :

• Le contrôleur de mise à jour, qui procéde aux vérifications nécessaires avant d'éxécuter l'action de Maj dans la base de données.
• Le contrôleur de vue, qui éxécute l'action de lecture les données à afficher et les met en forme.
• Le patron d'affichage qui intégre les restitutions des actions dans la page html complète où dans un message xml (dans le cas d'une requête Ajax).

Ce modèle semble proche du patron d'architecture logicielle Modèle-Vue-Contrôleur (MVC), mais je ne suis pas assez pointu dans ce domaine pour affirmer qu'il le respecte.

FrameBeurk est implémenté en PHP procédural et fonctionnel, sans utilisation des possibilités orientées objets du langage, pour une plus grande facilité d'accès aux développeurs et d'autres raisons qui feraient polémiques ici.

L'organisation des données en mémoire utilise largement (un peu plus à chaque version) les tableaux associatifs.

Une attention particulière a été portée à l'optimisation des performances :

• Réduction du nombre de requêtes sql nécessaires à chaque transaction,
• Amélioration de la durée du bootstrap par le stockage en session de la configuration du site,
• Réduction du nombre et du volume de données échangées entre le client web et le serveur, par une navigation Ajax optimale, par la fusion des fichiers css (ou javascript) des différents modules du site...

L'exposé réalisé dans cette documentation de la version v0.5 est d'un accès hétérogène : Certains points sont pour les personnes ignorant presque tout d'un framework, d'autres ne pourront faire sens qu'après examen des fichiers et du code de FrameBeurk.

Pour une 1ère approche, les chapitres 1 et 2 méritent d'être lus avant de passer au chapitre 8 -l'installation du framework.

Dans un second temps, reprendre l'étude à partir du chapitre 3 jusqu'au 9, qui expose une méthode d'analyse et de développement d'applications dans FrameBeurk.

Ce framework, comme sa documentation, est un travail toujours en cours. N'hésitez pas à me faire part de vos remarques constructives.

Vous pouvez parcourir dans cet explorateur toute l'arborescence des fichiers sources de FrameBeurk en v0.65. Cette version un peu plus avancée que celle de la documentation apporte :

• La gestion des langues : La fonction Beurk_traduit exploite des fichiers "Catalogues" contenant chacun un tableau associant libellés dans la langue d'implémentation du module aux libellés dans la langue cible.
  Les libellés à traduire sont extraits automatiquement par l'outil TraducTeurk. Une fois que le développeur a complété les traductions des libellés dans une feuille Excel, TraducTeurk génère les fichiers Catalogues.
Découvrir TraducTeurk
• La première version de l'Hypergraphe de FrameBeurk : La table Beurk_Lien met en relation les différentes entités manipulées.
  Les Terminaux déclarés dans la table Beurk_Terminal font le lien entre le code du framework (qui manipule leur libellé) et l'hypergraphe (qui stocke leur id numérique).