FrameBeurk documentation

9. Développement

Ce chapitre tente d’exposer concrètement une approche méthodologique descendante (top-down) du développement dans FrameBeurk d’applications de gestion au sens général, c’est-à-dire saisie de données, stockage et restitution - les traitements de ces données restant relativement simples (par exemple les calculs complexe ou modélisations sophistiquées ne sont peut-être pas adaptées).

Tout au long de ce tutoriel, sans que vous y soyez explicitement invités, il est recommandé de se reporter à la documentation descriptive du framework.

Exemple utilisé dans les paragraphes suivants :
Une application web de partage de musique

9. Développement
9.1. Etape 1 : Actions, entités, modules
9.1.1. Recherche des actions
9.1.2. Classement des actions
9.1.3. Classement des entités
9.2. Etape 1 : implémentation
9.2.1. Création de l’arborescence
9.2.2. Initialisation du fichier .sql
9.3. Etape 2 : Autorisations, clefs
9.3.1. Détermination des autorisations
9.3.2. Estimation des clefs des vues
9.4. Etape 2 : Implémentation
9.5. Etape 3 : Cartes, base de données, queries
9.5.1. Inventaire des Cartes
9.5.2. Contenu des Cartes
9.5.3. Base de données
9.5.4. Inventaire des Queries
9.6. Etape 3 : Implémentation
9.6.1. Les Cartes
9.6.2. Les Tables
9.6.3. Les Queries
9.7. Etape 4 : Intégration au site

9.1. Etape 1 : Actions, entités, modules

9.1.1. Recherche des actions

Cette étape doit répondre à la question : Quelles seront les actions que les utilisateurs de l’application pourront effectuer ? Sans distinction de profil d’utilisateurs, de précision sur l’enchainement des actions…
La réponse prend la forme d’une liste d’énoncés très simples « verbe + nom ». De cette liste doit émerger un nombre restreint de noms : Ce seront les entités auxquelles s’appliqueront les actions –les verbes.

Exemple :
Crée Bande, affiche Bande, liste Bande, crée Album, affiche Album, crée Morceau, modifie Morceau, supprime Morceau, vote Morceau, crée Commentaire…

Conseils :

Pour les actions : Limiter le nombre de verbe –réutiliser ceux déjà existant
Pour les entités : Les noms utilisés ne doivent pas exister dans un autre module (sauf si on réutilise ce module)
Pour les actions portant sur la relation de 2 entités, nommer cette relation en collant les noms des 2 entités.

Exemple :

« Bande » plutôt que « Groupe », qui est déjà utilisé dans le module Uzers.
« crée » plutôt que « ajoute », même si ce dernier a plus de sens.
« associe BandeArtiste » si on veut gérer la composition des Bandes…

Verbes à la 2^nde personne du singulier de l’impératif, en minuscule.
Noms au singulier, initiale en majuscule.
Si une entité semble complexe, penser à reporter la complexité sur l’action

Exemple :
« affiche Morceaux de l’Album » correspondrait à une Vue de l'entité Album qu’on pourrait nommer ainsi : « détaille Album », si « affiche Album » est une Vue présentant d’autres données.

9.1.2. Classement des actions

Dans la liste d’actions déterminée ci-dessus, il faut distinguer :

Celles qui ne font que restituer de l’information : les Vues
Celles qui entrainent une mise à jour des données : les Majs

Parmi ces Majs, celles qui, préalablement à leur exécution, nécessiteront l’affichage d’une Vue.

Exemple :
« crée Morceau » nécessite l’envoi d’un formulaire (donc une Vue), pas « vote Commentaire » qui est un simple bouton sur la page.

9.1.3. Classement des entités

La liste des actions a fait émerger une liste d’entités et il faut s’interroger sur l’intérêt de regrouper toutes ces entités dans le même module ou pas. Les séparer dans plusieurs modules entraîne une complexité et un coût supérieur par la gestion des appels de fonction entre modules indépendants (tissage), par la multiplication des fichiers de configuration, sql, css, js….

Le choix de la séparation en plusieurs modules répond aux questions : Est-ce que ce sous-groupe d’entités fortement couplées est faiblement couplé avec les autres ? Est-ce qu’il est susceptible d’être utilisé en dehors du contexte de cette application ?

9.2. Etape 1 : implémentation

9.2.1. Création de l’arborescence

Cette étape consiste à créer les répertoires et fichiers à vide du (des) modules, selon l’arborescence décrite au chapitre 4.2 (lecture fortement conseillée).

Dans le répertoire /modules, pour chaque nouveau module, créer un répertoire qui porte son nom
Dans chaque répertoire <module>, créer les répertoires « _sql », « _js », « _css » et pour chaque entité identifiée, un répertoire qui porte son nom.
Dans chaque répertoire <entité>, créer un répertoire « Vue » et un répertoire « Maj ».
Dans le répertoire « Vue », pour chaque action Vue identifiée, créer le fichier <action><Entite>.php.
Dans le répertoire « Maj », pour chaque action Maj identifiée, créer le fichier <action><Entite>.php.
Dans le répertoire « _sql », créer le fichier module<module>.sql
Dans le répertoire « _js », créer le fichier module<module>.js.php
Dans le répertoire « _css », pour chaque feuille de style gérée sur le site, créer un fichier module<module>_<style>.css.php

9.2.2. Initialisation du fichier .sql

Ce fichier contiendra tous les ordres nécessaires à la création ou mise à jour des objets de base de données lors de l’installation du module. A cette étape, alimenter les tables Beurk_Action et Beurk_TypeEntite avec les actions et entités identifiées.

Exemple :

INSERT INTO `Beurk_TypeEntite` (`TypeEntite`, `Module`) VALUES ('Album', 'Zeek'); INSERT INTO `Beurk_TypeEntite` (`TypeEntite`, `Module`) VALUES ('Bande', 'Zeek'); INSERT IGNORE INTO `Beurk_Action` (`Action`) VALUES ('affiche'); INSERT IGNORE INTO `Beurk_Action` (`Action`) VALUES ('cree'); …

9.3. Etape 2 : Autorisations, clefs

9.3.1. Détermination des autorisations

Pour chaque action identifiée à l’étape précédente, il faut déterminer à quelles conditions les utilisateurs seront autorisés à exécuter ces actions. Pour rappel, ce sont les contrôleurs Maj et Vue qui effectuent cette vérification, en appelant des fonctions apportées par les différents modules et qui sont définies par leurs fichiers de configuration. Si aucune fonction existante ne répond au besoin, il faudra que le module en cours de développement l’apporte.

Les profils apportés par les modules Beurk et Uzers sont :

« Tous » : Tous les utilisateurs
« Somme » : L’utilisateur doit renvoyer une somme de contrôle (équivalent du CAPTCHA)
« JetonClef » : Un jeton aléatoire valide doit être renvoyé (c’est le jeton qui définit l’action)
« Logue » : L’utilisateur doit être logué
« Createur » : L’utilisateur doit être le créateur de l’entité
« Admin » : L’utilisateur doit être associé au groupe ADMIN
« LogueOuSomme » : L’utilisateur doit être logué ou renvoyer une somme de contrôle
« AdminEtSomme » : L’utilisateur doit être associé au groupe ADMIN et renvoyer une somme de contrôle.
« Permission » : Une permission doit être paramétrée pour un des groupes auquel est associé l’utilisateur. Reportez-vous au chapitre décrivant le module Uzers pour comprendre cette fonctionnalité.

Exemple :

« affiche Bande », « affiche Morceau »… auront l’autorisation « Tous ».
« modifie Bande », « modifie Morceau »… auront l’autorisation « Createur ».
« crée Bande » aura l’autorisation « Admin » ou « Logue » si on veut autoriser d’autres utilisateurs identifiés à publier du contenu.

9.3.2. Estimation des clefs des vues

La clef d’accès à une vue est constituée de l’ensemble des paramètres nécessaires pour pouvoir se repositionner de manière univoque sur la Vue affichée. Dans FrameBeurk, les 3 paramètres obligatoires d’une Vue sont :

ActVue : Le code Action de la Vue
EntVue : Le type d’entité pour la Vue
IdVue : L’identifiant unique de l’entité (c’est un entier positif)

Certaines vues peuvent nécessiter des paramètres supplémentaires. Exemples :

Une Vue multipages aura en plus le paramètre « NoPage ».
Pour les Vues de création d’entité, l’identifiant IdVue n’est pas encore connu est sera nul. Si besoin, la référence à l’entité à laquelle sera rattachée celle créée sera portée par le paramètre supplémentaire « IdRef ».

Exemple :

« liste Bande », sera multipages est aura la clef supplémentaire « NoPage ».
Une Bande ne sera rattachée à aucune entité. « cree Bande » n’aura pas de clef supplémentaire.

9.4. Etape 2 : Implémentation

L’implémentation de l’étape 2 consiste à la déclaration des entités dans le fichier de configuration de module.
Le tableau associatif $CONFIG['Entites'] contient un élément par entité, qui lui-même contient le nom de son module d’appartenance, la liste des Majs et la liste des Vues.

Exemple pour l’entité Bande :

// Entité 'Bande' $CONFIG['Entites']['Bande'] = array( 'Module' => 'Zeek', 'Majs' => array('cree' => array('Auto' => 'Admin'), 'supprime' => array('Auto' => 'AdminEtSomme'), 'modifie' => array('Auto' => 'Admin')), 'Vues' => array('affiche' => array('Auto' => 'Admin', 'Clef' => array('NoPage')), 'cree' => array('Auto' => 'Admin'), 'liste' => array('Auto' => 'Admin', 'Clef' => array('NoPage')), 'supprime' => array('Auto' => 'Admin'), 'modifie' => array('Auto' => 'Admin'), 'previsualise' => array('Auto' => 'Admin')));

9.5. Etape 3 : Cartes, base de données, queries

9.5.1. Inventaire des Cartes

Une vue est composée de blocs d’informations indépendants nommés Cartes (fonctions PHP qui affichent le code HTML), qui sont réutilisables dans d’autres vues. Les Cartes présentent les données à afficher ainsi que les liens vers les actions de Maj qui sont possibles concernant ces données. Une vue d’une entité A peut afficher une Carte d’une entité B.

Exemple :

La vue « affiche Bande » sera composée d’une première carte « Bande » décrivant le groupe, puis d’une liste de cartes « Album ».
La vue « affiche Album » sera composée d’une carte « Bande », puis d’une carte « Album », puis d’une liste de cartes « Morceau ».
Les vues « cree Album » et « modifie Album » utiliseront la même carte « MajAlbum ».

9.5.2. Contenu des Cartes

Pour chaque Carte, il faut déterminer quelles seront les données à afficher et les données qui seront nécessaires pour établir les liens hypertextes vers les différentes actions.

Exemple :

La carte « Bande » affichera le nom du groupe, l’année de formation, de dissolution, un texte de description.
La carte « Morceau » affichera le titre du morceau, les paroles du morceau et un lien pour faire jouer le mp3 du morceau par le player du module.
Toutes les cartes du modules afficheront le nom du user, la date et l’heure de création.

9.5.3. Base de données

A cette étape, vous devez être capable de concevoir le modèle de données de chacun de vos modules, à partir des informations déterminées jusqu’à présent. La conception d’un modèle de données est hors du périmètre de ce tutoriel.

Exemple :
Toutes les tables auront un bandeau d’audit comportant l’Id du user qui crée l’enregistrement, les timestamps de création et de modification, un code état.

La table Bande contiendra les données fonctionnelles suivantes : Nom du groupe , un texte libre, année de formation, année de dissolution.
Un album sera caractérisé par un nom, un texte libre, une année de sortie et rattaché à une bande.
Un morceau par un nom, un texte libre, un fichier mp3, et sera rattaché à un album.

9.5.4. Inventaire des Queries

En règle générale, une Carte affiche le résultat d’une Query (pour rappel : Une Query est une fonction PHP renvoyant une requête SQL). Les colonnes sélectionnées dans une query doivent donc être adaptées à la Carte à afficher.

Une même carte peut être appelée dans des contextes différents : par exemple sur une vue de détail et sur une vue liste. Il peut donc y avoir plusieurs Queries adaptée à une Carte -la clause de sélection étant l’élément variable.

Exemple :
A l’entité Album seront attachées les queries ramenant :

Tous les albums
Tous les albums d’une Bande
Un album précisé par son Id
Les albums répondant aux critères de recherche de l’action « rechercheSite »

9.6. Etape 3 : Implémentation

9.6.1. Les Cartes

A suivre… En attendant, s’enivrer des cartes du fichier helpersRhum.php.

9.6.2. Les Tables

Les ordres de créations des tables sont stockés au niveau du module dans le fichier « module<module>.sql ». Ils peuvent être saisis manuellement ou obtenu par export de la description de la table préalablement créée dans phpmyadmin (pour mysql).

Respecter certaines règles permet de mutualiser certains traitements. Par exemple, pour toutes les tables répondant aux 3 points suivants, on pourra utiliser la fonction Uzers_CreateurEntite() pour retrouver le créateur de la ligne :

La table principale de l’entité sera nommée « module _entite »
Elle aura un identifiant unique nommé « IdEntité »
L’Id de l’utilisateur ayant créé la ligne sera stockée dans la colonne « IdCreateur ».

Exemple :
La table Zeek_Bande aura les colonnes suivantes :

IdBande clef unique de la table int(10) unsigned Bande nom du groupe varchar(64) Donnees text IdCreateur id du créateur de la ligne int(10) unsigned TsCRE Timestamp de création bigint(20) TsMaj Timestamp de la dernière mise à jour bigint(20)

9.6.3. Les Queries

A suivre… En attendant, s’enivrer des queries du fichier modeleRhum.php.

9.7. Etape 4 : Intégration au site

Pour que l’application que vous avez définie aux étapes précédente soit accessible aux utilisateurs, elle doit lui être intégrée et présenter des points d’accès aux entités, par exemple :

Un lien dans le menu commun du site pointant vers une vue depuis laquelle l’utilisateur pourra –directement ou indirectement, atteindre tout le contenu qui lui est destiné,
La gestion des nouvelles entités par le widget commun de recherche du site,
Un nouveau widget spécifique qui sera intégré dans le layout du site.

8. Installation << Sommaire >> 10. Miscellaneous