Les profils

Module d’exemple : hellotypes, propriété editabledata.

hasprofile:true sur une propriété est le mécanisme le plus rentable du framework : un seul booléen, et la propriété gagne la sauvegarde/chargement de configuration nommée en base, sans écrire une seule ligne de code.

"editabledata": {
  "permission": 2,
  "hasprofile": true,
  "e": { "..." }
}

Ce que ce flag déclenche, entièrement automatique

  • Sauvegarde/chargement : un client envoie PS/PL avec un nom de profil ; le serveur construit un instantané limité aux propriétés hasprofile:true et l’écrit en base (ou le relit). Déjà géré génériquement par le framework — rien à écrire dans le module.
  • Côté interface : la boîte “Paramètres” d’un module ne liste que les propriétés hasprofile:true ; la barre de chargement/sauvegarde de profil n’apparaît que s’il en existe au moins une.
  • Deux listes de valeurs, également automatiques : chaque module a sa propre liste de profils sauvegardés (vide au départ, alimentée à chaque sauvegarde), et le contrôleur maintient en plus une liste agrégée par type de module, utilisée par le sélecteur de profil de l’interface.
Quasiment tous les modules réels l’utilisent

C’est le mécanisme standard pour toute configuration que l’utilisateur doit pouvoir nommer, retrouver et recharger — réglages de caméra, paramètres de séquence, profil d’autofocus… Un module qui expose des réglages persos devrait presque toujours en avoir au moins une propriété hasprofile:true.