--- title: "Système Generic Form" module: form type: functional status: active updated: 2026-06-22 --- # Système Generic Form Le système **generic-form** est le moteur de formulaires d'ISI-APP. Il permet d'afficher, créer, modifier et supprimer n'importe quelle entité applicative via une URL unifiée, avec un mécanisme de personnalisation par module (hooks) sans toucher au code commun. --- ## URL et actions disponibles Toutes les pages de formulaire passent par la route `mod` : ``` /mod/{moduleId}/{action}/{id} ``` | Action | Description | |--------|-------------| | `create` | Formulaire de création | | `update` | Formulaire de modification | | `delete` | Archivage de la donnée | | `see` | Fiche de visualisation (lecture seule) | | `home` | Liste principale du module | **Exemples :** - `/mod/{modidelement}/update/42` — modifier l'entité #42 - `/mod/{modidelement}/create` — créer une nouvelle entité - `/mod/{modidelement}/see/42` — consulter la fiche de l'entité #42 --- ## Ce que le système fait automatiquement Pour chaque module enregistré dans l'application, le système prend en charge : - **Chargement des données** : récupération automatique de l'entité en BDD selon l'ID dans l'URL. - **Contrôle d'accès** : vérification des droits lecture/écriture/suppression avant tout affichage ou écriture. - **Génération du formulaire** : les champs, leur type, leurs règles de validation et leurs options sont définis dans la configuration du module. - **Écriture en BDD** : insertion ou mise à jour gérée par le moteur, avec gestion des transactions. - **Navigation par onglets** : pour les modules principaux, les sous-modules apparaissent automatiquement sous forme d'onglets. - **Sidebar d'actions** : boutons Archive/Restauration, historique d'activité, et actions métier custom. - **Alertes** : affichage des messages d'erreur et d'information au-dessus du formulaire. - **Mode modal / overlay** : le même formulaire peut s'ouvrir en pop-up via `?dm@=modal` dans l'URL. --- ## Formatage de donnée d'un champ Dans le paramétrage d'un champ (bouton « Paramétrage du champ »), l'option **« Formatage de donnée »** permet de nettoyer/forcer automatiquement la saisie de l'utilisateur. C'est un champ **libre** : on y saisit l'un des codes ci-dessous (un seul code par champ). | Code | Effet sur la saisie | |------|---------------------| | `MAJ` | Tout en MAJUSCULES | | `FORNAME` | 1ʳᵉ lettre de chaque mot en majuscule (prénoms, ex. « Jean-Pierre ») | | `MIN` | Tout en minuscules | | `SIR` | Format SIRET : ne garde que les chiffres, limité à 14 | | `TEL` | Format téléphone : ne garde que les chiffres et le « + » | > Exemple : pour qu'un champ se comporte comme un SIRET, saisir `SIR` dans « Formatage de donnée » ; > pour un numéro de téléphone, saisir `TEL`. Le nettoyage est identique à celui des formulaires dynamiques. --- ## Structure d'une page formulaire ``` ┌────────────────────────────────────────────────────────────┐ │ Alertes / Callouts (si conditions métier non remplies) │ ├────────────────────────────────────────────────────────────┤ │ Navigation pills / onglets │ ├──────────────────────────┬─────────────────────────────────┤ │ SIDEBAR │ FORMULAIRE PRINCIPAL │ │ • Actions métier │ • Champs de saisie │ │ • Archive / Restaurer │ • Informations complémentaires │ │ • Historique activité │ │ ├──────────────────────────┴─────────────────────────────────┤ │ Onglets secondaires (RH, Tickets, Matériels, Droits…) │ └────────────────────────────────────────────────────────────┘ ``` --- ## Mécanisme de personnalisation : les Hooks Chaque module peut personnaliser le comportement du système via des fichiers de hook, nommés d'après les 6 premiers chiffres de l'ID du module (le `{modid}`). ### Hooks PHP (logique serveur) Ces fichiers PHP se trouvent dans `/hook/` et sont exécutés automatiquement par le moteur : | Fichier | Quand | Ce qu'il permet | |---------|-------|-----------------| | `{modid}.ctlbefore.php` | Avant tout traitement | Redirections, vérifications d'accès supplémentaires | | `{modid}.form.php` | Lors de la génération du formulaire | Masquer/afficher des champs selon le contexte, valider des règles métier, injecter des valeurs | | `{modid}.db_after.php` | Après l'écriture en base | Déclencher des actions en cascade (mise à jour d'autres tables, invalidation de cache) | **Exemple :** Pour un module donné, le hook `form.php` peut masquer automatiquement des champs selon le contexte (ex : champs médicaux masqués pour les structures non-santé). ### Hooks Blade (personnalisation de l'interface) Des vues Blade spécifiques peuvent être placées dans `resources/views/hook/custom/` pour enrichir l'interface : | Vue | Ce qu'elle permet | |-----|------------------| | `alerts/{modid}.blade.php` | Afficher des alertes métier (ex: utilisateur sans profil) | | `stats/{modid}stats.blade.php` | Compteurs statistiques (tickets, matériels, projets…) | | `sidebar-header/{modid}.blade.php` | En-tête de la sidebar, au-dessus des actions (ex: photo de profil, boutons email/téléphone) | | `ctl/{modid}ctl.blade.php` | Boutons d'actions dans la sidebar (ex: réinitialiser le mot de passe) | | `wire/form/{modid}wire.blade.php` | Formulaire Livewire entièrement personnalisé | | `addons-header/{modid}add.blade.php` | Contenu additionnel avant le formulaire (ex: callout de relation mère/fille) | | `tabcontent/{modid}/{tabId}.blade.php` | Contenu des onglets secondaires | | `addons/{modid}add.blade.php` | Contenu additionnel après le formulaire (ex: liste de sous-entités liées) | --- ## Modes d'affichage (`dm`) Le paramètre `dm@` dans l'URL contrôle comment le formulaire s'affiche : | Valeur | Comportement | |--------|-------------| | `classic` (défaut) | Page complète avec layout principal | | `modal` | Formulaire dans une modale (popup) | | `overlay` | Formulaire en panneau latéral | | `ajax` | Réponse HTML partielle pour injection AJAX | --- ## Gestion des erreurs et blocages Un hook peut **bloquer l'écriture** en base en positionnant `$this->return['result'] = false` et en créant une alerte via `createAlert()`. L'alerte est alors affichée au-dessus du formulaire. **Exemples de blocages existants :** - Tentative de créer un utilisateur avec un email déjà existant → alerte rouge, formulaire non soumis. - Tentative de supprimer l'utilisateur connecté → message d'erreur explicite. - Utilisateur sans droits suffisants tentant de modifier un autre utilisateur de la structure → rejet. --- ## Fiche de visualisation (`see`) L'action `see` affiche une fiche de consultation en lecture seule, distincte du formulaire de modification. Chaque module dispose d'une vue dédiée dans `resources/views/see/{modidelement}.blade.php`. La fiche affiche par exemple : coordonnées, rôles projet, matériels rattachés, tickets ouverts, fonctions RH. --- ## Sous-modules et onglets Les modules principaux (`modidel = 01`) peuvent avoir des sous-modules (onglets). Ces onglets sont générés automatiquement à partir de la configuration du module et affichés sous forme de pills de navigation. **Exemple pour un module principal :** - Onglet 1 : Informations générales (formulaire principal) - Onglet Tickets : liste des tickets de l'utilisateur - Onglet RH : postes et missions - Onglet Informatique : matériels associés - Onglet Droits : profils d'accès Chaque onglet peut avoir une vue custom dans `hook/custom/tabcontent/{modid}/`. --- ## Résumé — Ce qu'un module doit fournir Pour qu'un module soit complet dans le système generic-form, il faut : 1. **Configuration BDD** — enregistrement dans les tables `_mod` et `_mod_element`. 2. **`hook/{modid}view.blade.php`** — point d'entrée Blade du module. 3. **`hook/{modid}.form.php`** — logique de personnalisation du formulaire. 4. **`hook/custom/wire/form/{modid}wire.blade.php`** — formulaire Livewire avec champs configurés. 5. **`hook/custom/ctl/{modid}ctl.blade.php`** — actions métier dans la sidebar (optionnel). 6. **`hook/custom/alerts/{modid}.blade.php`** — alertes contextuelles (optionnel). 7. **`hook/{modid}.db_after.php`** — side-effects post-écriture (optionnel).