Je suis en train de créer un outil Web qui permet à l'utilisateur de générer un paquet d'options sous la forme d'une chaîne. Pour sélectionner les options qu'il souhaite, il utilise un formulaire avec différentes entrées (radio, case à cocher) qui est généré à partir d'un dictionary.json qui contient actuellement toutes les options disponibles et leurs codes dans le format suivant (sujet à changement ):
[
{
"id": 0001,
"title":"foo",
"type":"radio",
"options":[
{
"bar":"",
"foo":"489",
"foobar":"489+490"
}
]
},
{
"id": 0002,
"title":"something",
"type":"check",
"options":[
{
"everything":"M016",
"evenmore":"M139"
}
]
},
[...]
Comme vous pouvez le voir, c'est essentiellement une petite base de données. Le problème est que les options dépendent les unes des autres, donc si foo est foobar , cela pourrait déterminer que quelque chose est certainement encore plus code > et ne peut PAS être changé en tout . Comment mapper ces dépendances dans dictionary.json afin que le formulaire généré puisse griser de manière fiable les options déterminées par d'autres choix?
Le La structure doit être flexible pour que de nouvelles dépendances puissent être insérées et généreraient le nouveau formulaire de manière fiable ou valideraient les sorties existantes par rapport à elles. Il pourrait également y avoir des options qui dépendent de plusieurs autres options. Je ne peux pas penser à un moyen intelligent de sauvegarder ces dépendances et je me demande si JSON est le bon format pour aller avec ici.
Tous les conseils ou idées sont les bienvenus. Merci!
3 Réponses :
Vous pouvez essayer de sauvegarder chaque option comme un objet qui stocke toutes les options qui seront exclues si cette option est sélectionnée. Ainsi, votre JSON pourrait ressembler à ce qui suit:
"isExcludedBy": [
"id": 0001,
"options": [
"foobar"
]
]
Chaque fois qu’une option est sélectionnée, vous devrez vérifier sa liste d’exclusions et activer toutes ces options pour les champs spécifiques.
Pour améliorer la convivialité, vous pouvez vérifier qu'il ne reste qu'une seule option pour un champ, sélectionnez cette option, puis désactivez tout le champ.
MODIFIER:
De plus, vous pouvez enregistrer un champ isExcludedBy dans chacune des options.
L'option tout de id 0002 ressemblerait alors à ceci:
[
{
"id": 0001,
"title":"foo",
"type":"radio",
"options":[
{
"bar":"",
"excludes": []
},
{
"foo":"489",
"excludes": []
},
{
"foobar":"489+490",
"excludes": [
{
"id": 0002,
"options": [
"everything"
],
},
{
"id": 0003,
"options": [
"apple",
"cherry"
],
},
]
}
]
},
{
"id": 0002,
"title":"something",
"type":"check",
"options":[
{
"everything":"M016",
"excludes": []
},
{
"evenmore":"M139",
"excludes": []
}
]
},
[...]
Ce serait un peu redondant, mais en fonction sur ce que vous voulez que votre interface utilisateur affiche, cela pourrait vous faire gagner du temps informatique.
Une solution simple possible (qui répond à votre question):
[["0001", "foobar"], [["0002", "evenmore"], ["0003", "namaste"]]]
dépendances ici se composent de paires de [ chemin vers l'option dans les options qui implique une autre option , chemin vers l'option implicite ].
Vous pouvez créer une structure de données Map directement à partir de cela (les options implicites sont des clés, les implicites sont des valeurs).
Ceci suppose qu'une option ne peut impliquer qu'une seule autre option ( mais cela permet toujours des options qui dépendent de plusieurs autres options ).
Vous pouvez bien sûr facilement étendre cela comme ceci:
// dictionary.json
{
"options": [
{
"id": 0001,
"title":"foo",
"type":"radio",
"options":[
{
"bar":"",
"foo":"489",
"foobar":"489+490"
}
]
}
// etc.; same as before
],
// this is it:
"dependencies": [
[["0001", "foobar"], ["0002", "evenmore"]],
]
}
Cela signifierait que "0001" / "foobar" implique à la fois "0002" / "evenmore" et "0003" / "namaste" code>. Mais peut-être YAGNI. :)
Une façon d'aborder cela est de modéliser le domaine que vous exprimez réellement et de générer le formulaire en fonction de cela. Par exemple, nous savons que les appartements ont des numéros de rue et des numéros d'appartement, alors que les péniches n'ont même pas de rue.
{
"dwelling": {
"type": "apartment",
"street": "Beech St.",
"street_number": 123,
"apartment_number": 207,
}
}
ou
{
"dwelling": {
"type": "houseboat",
"latitude": null,
"longitude": null,
}
}
En modélisant le domaine plutôt que le formulaire, vous pouvez écrire des règles qui s'appliquent au-delà du formulaire, et vous n'aurez pas à développer un mini-langage pour exprimer les dépendances de formulaire.
Comment aborderiez-vous les dépendances avec cette approche?
@ omel09 vous n'avez pas besoin d'exprimer les dépendances avec cette approche. Vous auriez une routine pour le rendu des péniches et une autre pour le rendu des appartements. Le rendu de la péniche n'inclurait pas le numéro de rue et le rendu de l'appartement n'inclurait pas la longitude.
Je recommanderais de jeter un œil à Joi: npmjs.com/package/@hapi/joi. Vous pouvez valider presque tous les objets JSON avec des schémas joi vraiment complexes et extensibles.
@AnandUndavia merci pour votre commentaire. Je ne sais pas comment cela s'appliquerait ici car la seule validation qui a lieu est si un jeu de règles (chaîne) est "autorisé" comme dans "il ne contient pas de règles qui s'excluent mutuellement"
Les options sont-elles exclusives à un seul objet ou au
"type"? Par exemple. l'option"bar"peut-elle apparaître sur d'autres objets et / ou types?