3.1. Bootstrap

Le premier traitement exécuté -quelque soit le point d’entrée, est l’appel du bootstrap. Celui-ci effectue toutes les opérations préparatoires au bon déroulement de la transaction :

La couche de communication avec la base de données doit définir toutes les fonctions de lecture/mise à jour utilisées dans les modules. Actuellement, les 2 fichiers livrés avec le framework sont des surcouches des interfaces mysql et mysqli.

3.2. Contrôleurs

La notion de contrôleur est ici quelque peu différente de celle du modèle MVC. Dans FrameBeurk, n’importe quel partie de script ayant une liste à sa disposition, notamment pour vérifier que la valeur d’une variable qu’on lui envoie est présente dans la liste, peut prétendre être nommé contrôleur. Les principaux sont :

3.2.1. Contrôleur de Maj

Il reçoit les variables standard pour une Maj et vérifie la compatibilité de leurs valeurs avec la configuration chargée par le bootstrap. Notamment : le type d’entité de l’action doit exister, le code Maj doit exister pour cette entité, le profil de l’utilisateur doit être autorisé à cette action…
Lorsque tous les contrôles sont OK, le code de l’action de Maj est exécuté.

3.2.2. Contrôleur de Vue

Le principe est le même que pour le précédent. Il reçoit et vérifie les valeurs des variables clef pour la Vue demandée : Le type d’entité de l’action doit exister, le code Vue doit exister pour cette entité, le profil de l’utilisateur doit être autorisé à cette action…
Lorsque tous les contrôles sont OK, le code de l’action de Vue est exécuté.

3.2.3. Contrôleur de DivPatron

Ce contrôleur doit être inséré dans le patron pour chaque div dans laquelle du contenu dynamique doit être inséré.
Il balaie la liste des divs paramétrées dans le fichier de configuration et insère celle dont le nom correspond, avec leur contenu qui peut être (1 ou plusieurs parmi) : libellé statique, variable PHP, contenu généré par une vue, widget.

3.3. Points d’entrée

Le point d’entrée dans le framework varie selon le type de données retournées (html, rss, css, js) et, pour le code html, si la page complète doit être affichée ou seulement une vue (Ajax).

Ci-après les cinématiques des différents points d’entrées.

3.3.1. index.php et ajax.php

Les cinématiques sont identiques pour les deux, à l’exception du patron utilisé pour la sortie du code html.
Ils partagent donc le même schéma :

En cas de réécriture d’URI, le serveur http doit être paramétré pour substituer « interpreteur.php » à « index.php » et « ajax.php ». Dans ce cas, c’est seulement l’interpreteur qui charge le bootstrap.
L’interpréteur a pour fonction d’analyser l’URI réécrite pour alimenter les variables PHP qui sont habituellement traitées par index.php et ajax.php

3.3.2. css.php

FrameBeurk peut gérer plusieurs styles pour le même site, à choisir par l’utilisateur ou par paramétrage.
Ce script envoie dans un seul fichier toutes les déclarations css associées aux différents modules et au patron, selon le style sélectionné.

3.3.3. js.php

De même, ce script envoie dans un seul fichier toutes les déclarations javascript associées aux différents modules et au patron.

3.3.4. rss.php

Ce point d’entrée est destiné à l’alimentation des flux rss. Il n’utilise donc pas le contrôleur de Maj.

3.4. Action Maj

Le code d’une action de Maj contiendra typiquement les paragraphes suivants :

• Vérification des données transmises par l’utilisateur
• Lecture en base de données  de l’entité impactée (le cas échéant)
• Vérification de leur cohérence avec l’action demandée
• Exécution de l’ordre SQL impactant l’entité
• Message d’erreur ou de réussite de l’action

3.5. Action Vue

Les actions de Vue sont fréquemment plus complexes et seront utilement décomposées de manière à séparer le code SQL des requêtes d’accès à la base de données, de la génération du code HTML.

Les Vues seront donc constituées d’une succession d’appels à des fonctions PHP renvoyant les éléments suivants :

3.5.1. Query

Une Query est une fonction PHP renvoyant une requête SQL de lecture de la base de données, soit sous la forme d’une chaine de caractère, soit sous la forme d’un tableau (voir plus loin le paragraphe « Couche de communication avec la DB »).

Les Queries sont regroupées par entité dans un fichier modèle situé dans le répertoire de l’entité.

3.5.2. Carte

Une carte est une fonction PHP générant un bloc de code HTML à partir du ResultSet obtenu par l’exécution d’une Query. Typiquement, la carte met en forme les données d’une entité et propose les actions de Maj possibles en fonctions de l’état de l’entité et du profil de l’utilisateur.

Les Cartes sont regroupées par entité dans un fichier helpers situé dans le répertoire de l’entité, ou directement dans le répertoire d’un module si le code est mutualisé entre plusieurs entités.