Lorsque le contenu d’un widget de formulaire de type select est en dur, par exemple les jours de la semaine, on crée en base de données une colonne de type varchar() puis on surcharge la classe métier afin de typer le champ et définir ses options.
Le langage SQL permet la création de types énumération pour les ensembles prédéfinis de valeurs statiques. Faire comme cela permettrait :
d’effectuer un contrôle sur la valeur par la base de données;
de ne plus avoir à surcharger la classe métier.
Pour ce dernier point et c’est l’objet de ma réflexion cela nécessite une évolution du générateur du framework afin qu’il puisse automatiquement gérer les ENUM en liste déroulante, comme il le fait déjà pour les clés étrangères.
Je pense que tous ce qui peut être porté par la base de données est une bonne idée car on met en place un contrôle au niveau le plus bas et cela participe à la solidité du modèle.
Cependant avec enum, je pense que la limite est que cela ne gère pas une valeur affichée différente de la clé.
Pour les jours de semaine, on peut utiliser 2 valeurs dans le système du select surchargé : la clé et la valeur d affichage qui pourrait servir à une traduction : “lundi” et (“lundi”)
Un autre cas d’utilisation est l utilisation pour des paramètres de traitement : exemple : état d’un courrier ou d une tache. Dans ce cas on souhaite que la clé du select soit contrôlé par le programme et il y a souvent une valeur d’affichage pour une meilleure compréhension de l utilisateur.
Peut être le rajout d’une table unique table-champ-cle-valeur résoudrait ce pb ?
exemple : courrier|etat|envoyer|(“envoyer au correspondant”)
courrier|jour|lundi|_(“lundi”)
En effet le libellé de l’option est amené à être différent de sa valeur. Si le libellé généré est une chaîne à traduire de modèle _(‘enum_valeur’) cela affine les possibilités de traduction. Et le code source peut continuer à contrôler la valeur.
De plus si le programme essaie d’ajouter une valeur non existante dans le type énumération soit c’est une erreur du développeur soit le modèle doit être changé. Actuellement ce cas est géré mais le message d’erreur est générique.
Je pense que les problématiques soulevées par le ENUM sont facilement corrigibles alors que créer une nouvelle table complexifierai le travail du générateur et du développeur.
Oui effectivement, il vaut mieux éviter de complexifier le générateur avec l ajout d une table supplémentaire.
Dans ta proposition, ce qui me plait, c est surtout de faire porter le contrôle par postgres et de ne pas avoir de surcharge…
Est ce que ta proposition serait que l’affichage du select pourrait être une valeur du style : _(“valeur”) dans le code qui pourrait être traduite par le développeur pour être compréhensible ?
Exactement, si ce n’est qu’en prévision d’éventuels conflits de traduction je serais d’avis de préfixer la valeur dans la chaîne à traduire.
Pour l’exemple du lundi il se peut que dans l’application _("lundi") soit déjà traduit en lundi. Dans la liste déroulante, en traduisant _("enum_lundi") on pourrait juste afficher la lettre L.