Il existe deux types de modèles : les modèles de tables initiales et les modèles de GOT
Modèles de tables initiales :
Également appelés modèles techniques,
- Ils sont automatiquement créés lors de la création des tables et portent leur nom, sous deux formes possibles...
- Ils comprennent toutes les rubriques de la table, en brut
- Ces modèles ne sont accessibles qu’au développeur (sauf dans les solutions « ouvertes ») et leur but est utilitaire
nom des modèles de tables initiales ou modèles techniques :
- ils décrivent la table et indiquent son trigramme. Pour éviter toute confusion dans une liste avec les modèles "utilisables", la structure est donc Nom_XXX (nom en Camel puis underscore puis trigramme en majuscules)
- par souci de cohérence avec les noms de tables et d'OT, ils commencent par le trigramme et indiquent clairement leur fonction : XXX_Tech ou XXX_Raw (Trigramme en majuscules puis underscore puis tech ou raw en Camel).
Modèles de GOT
- Les modèles sont TOUJOURS placés sur l’ancre (source) du GOT
- Leur nom est au maximum de 42 caractères
- Ils sont normalement accessibles aux utilisateurs
- Obtenir(NomTableModèle) renvoie le nom de l’ancre sur laquelle est posé le modèle, ce qui permet au besoin de vérifier le nom de la table source associée
- Structure des noms de modèles : OTsource_Nom{_FonctionComplément}
- La logique de la nomenclature ci-dessus permet de ne noter que le GOT au lieu de l’OT source. Tous les modèles devant nécessairement se rapporter à l’ancre. (on fait donc une économie de caractères, et on simplifie le tri)
- Nom et OTsource sont obligatoires
- L’OTsource peut être exprimée soit par les initiales soit par le nom complet s’il est court. Ce Nom peut renseigner la fonction principale et doit être explicite
- Au bénéfice de la clarté, nous privilégions de n'utiliser QUE les trigrammes, puis « _ », puis le nom.
Par exemple, sont créés d’office XXX_Fiche et XXX_Liste (en plus de XXX_Tech), et éventuellement d’autres selon besoin. Cela permet de créer des scripts de navigation qui s’affranchissent de leur contexte : on ne cherche que « Fiche » si on est sur une liste, etc.)
- Si nécessaire les fonctions complémentaire (_FonctionComplément) sont codées et séparées par des | (pipe = alt maj L) comme suit :
d = modèle développeur ou ne servant pas d’interface utilisateur (par défaut, l’absence de cette lettre indique un modèle faisant l’objet d’une interface utilisateur)
s = modèle utilisé par un script. Attention, sauf pour cibler un modèle, on évitera d’utiliser les noms de modèle en dur dans les scripts ou fonctions, remplacé par Obtenir(NomModèle)
ZZZ (trois Z majuscules) pour les modèles en attente n’étant encore aucunement utilisés (penser à supprimer le ZZZ dès que ce modèle a une utilisation). Ce symbole peut aussi être réservé à un modèle « template », contenant des rubriques « essentielles » : ZZZ_Template, à garder précieusement…Version « Adavnced », évidemment)
Exemples :
FAC_Impression = OT factures, modèle impression, vu par l’utilisateur, non utilisé dans un script.
FAC_Recherche_d|s = OT factures, modèle recherche, utilisé par le développeur mais pas par l’utilisateur et dans au moins un script
FAC_Liste_ZZZ = ce modèle n’est pas utilisé par l’application (FAC_Liste_ZZZ)
- Règle de bonne pratique : regrouper les modèles par GOT, et séparer chaque groupe de modèles par un modèle « - », blanc. Ne pas laisser visibles les modèles utilitaires dans la liste des modèles.