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}

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).

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 :

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 :

Modes d'affichage (dm)

Le paramètre dm@ dans l'URL contrôle comment le formulaire s'affiche :

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).