Anomalie #642
fermé
Incohérence dans la vérification d'unicité d'un champ supplémentaire
Ajouté par Guillaume Rousse il y a presque 11 ans.
Mis à jour il y a plus de 10 ans.
Description
L'enchainement des étapes suivantes est impossible:
- créer un champ 'foo', de type séparateur > OK
créer un champ 'foo', de type 'choix' > OK
définir les valeurs possibles pour le 2e champ foo -> erreur 'il existe déjà un champ foo'
Par contre, l'enchainement suivant est possibe:
- créer un champ 'foo', de type 'choix' > OK
définir les valeurs possibles pour le 2e champ foo > OK
créer un champ 'foo', de type séparateur -> OK
L'incohérence vient de la vérification de l'unicité du champ, qui n'est faite qu'au moment de la définition de ses propriétés, pas lors de sa création.
Ceci dit, tant que les champs ont des identificateurs interne distincts, il n'est pas forcément nécessaire d'imposer l'unicité de leur nom. Un simple avertissement pourrait éventuellement suffire, au moment de la création.
- Version utilisée changé de 0.7.6 à 0.7.4
- Version cible mis à 0.7.5
- Catégorie mis à Core
- Assigné à mis à Johan Cwiklinski
Guillaume Rousse a écrit :
Ceci dit, tant que les champs ont des identificateurs interne distincts, il n'est pas forcément nécessaire d'imposer l'unicité de leur nom. Un simple avertissement pourrait éventuellement suffire, au moment de la création.
Oui mais ça va poser problème lors des traductions ; et je n'en vois pas l'intérêt. Galette propose des champs répétables de différents types, quelle pourrait être la raison d'avoir deux champs dynamiques qui portent le même nom ?
D'après ce que j'en vois, la recherche des duplicatas ne s'effectue que dans editer_champ.php, et effectivement pas du tout lors de la création.
Galette propose des champs répétables de différents types, quelle pourrait être la raison d'avoir deux champs dynamiques qui portent le même nom ?
Le fait que les séparateurs, cad des éléments visuels, soient implémentés comme des champs, et donc polluent artificiellement l'espace de nommage, par exemple. Ou qu'il peut être souhaitable d'avoir deux champs intitulés de la même manière, mais dans deux sections différentes.
Rendre plus explicite d'une façon ou d'une autre le fait que cet attribut 'nom' correspond en fait à un identifiant (avec contrainte d'unicité), et que ce qui est affiché correspond à la traduction de celui-ci dans la langue courante (sans contrainte d'unicité), me convient également. C'est juste peu intuitif pour un nouvel utilisateur.
Guillaume Rousse a écrit :
Galette propose des champs répétables de différents types, quelle pourrait être la raison d'avoir deux champs dynamiques qui portent le même nom ?
Le fait que les séparateurs, cad des éléments visuels, soient implémentés comme des champs, et donc polluent artificiellement l'espace de nommage, par exemple. Ou qu'il peut être souhaitable d'avoir deux champs intitulés de la même manière, mais dans deux sections différentes.
Rendre plus explicite d'une façon ou d'une autre le fait que cet attribut 'nom' correspond en fait à un identifiant (avec contrainte d'unicité), et que ce qui est affiché correspond à la traduction de celui-ci dans la langue courante (sans contrainte d'unicité), me convient également. C'est juste peu intuitif pour un nouvel utilisateur.
Hum... Je verrai selon ce qu'il est possible de faire sans tout péter, et sans y passer une semaine surtout. Les histoires de champs dynamiques et de traduction prises à part dont déjà fort compliquées, les deux ensembles ; c'est juste le bordel, je préfère éviter trop de modifications de ce côté là pour ma part...
Le jour où on pourra faire des tests unitaires dans Galette, ce sera probablement moins problématique, en attendant, c'est moi qui me les farcis, et j'en oublie souvent plus de la moitié :(
- Version cible changé de 0.7.5 à 0.7.6
- % réalisé changé de 0 à 100
- Statut changé de Nouveau à Fermé
Formats disponibles : Atom
PDF
Mis à jour par 
Mis à jour par