在 JSON 结构中映射依赖关系
Map dependencies in JSON structure
我目前正在构建一个 web 工具,它使用户能够生成字符串形式的选项包。对于 select 他想要的选项,他使用了一个具有不同输入(单选框、复选框)的表单,该表单是从 dictionary.json
生成的,该表单当前包含以下格式的所有可用选项及其代码(可能会更改) :
[
{
"id": 0001,
"title":"foo",
"type":"radio",
"options":[
{
"bar":"",
"foo":"489",
"foobar":"489+490"
}
]
},
{
"id": 0002,
"title":"something",
"type":"check",
"options":[
{
"everything":"M016",
"evenmore":"M139"
}
]
},
[...]
如您所见,它基本上是一个小型数据库。问题是选项相互依赖,所以如果 foo
是 foobar
它可能会确定 something
肯定是 evenmore
并且不能更改为 everything
. 我如何在 dictionary.json
中映射这些依赖项,以便生成的表单能够可靠地将由其他选择确定的选项变灰?
结构必须灵活,以便可以插入新的依赖项并可靠地生成新表单或根据它们验证现有输出。也可能有依赖于多个其他选项的选项。我想不出一种保存这些依赖关系的聪明方法,我想知道 JSON 是否适合这里的格式。
欢迎任何提示或想法。谢谢!
您可以尝试将每个选项保存为一个对象,该对象存储所有选项,如果该选项被 selected,这些选项将被排除。
因此,您的 JSON 可能如下所示:
[
{
"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": []
}
]
},
[...]
每次 select 编辑一个选项时,您都必须检查他们的排除列表并禁用特定字段的所有这些选项。
为了提高可用性,您可以检查一个字段只剩下一个选项,select 这个选项,然后禁用整个字段。
编辑:
此外,您可以为每个选项保存一个 isExcludedBy
字段。
id 0002
的 everything
选项将如下所示:
"isExcludedBy": [
"id": 0001,
"options": [
"foobar"
]
]
这有点多余,但根据您希望 UI 显示的内容,它可以为您节省一些计算时间。
可能的简单解决方案(回答您的问题):
// 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"]],
]
}
dependencies
由成对的 [path to option in options
暗示另一个选项, path to the implied option ]。
您可以直接从中创建一个 Map
数据结构(隐含的选项是键,隐含的是值)。
这假设一个选项只能暗示另一个选项(但它仍然允许选项依赖于多个其他选项)。
您当然可以像这样轻松扩展它:
[["0001", "foobar"], [["0002", "evenmore"], ["0003", "namaste"]]]
这意味着 "0001"/"foobar"
意味着 "0002"/"evenmore"
和 "0003"/"namaste"
。但也许是 YAGNI。 :)
解决此问题的一种方法是对您实际表达的域建模,并基于该域生成表单。比如,我们知道公寓有门牌号,门牌号,而船屋连门牌号都没有。
{
"dwelling": {
"type": "houseboat",
"latitude": null,
"longitude": null,
}
}
或
{
"dwelling": {
"type": "apartment",
"street": "Beech St.",
"street_number": 123,
"apartment_number": 207,
}
}
通过对域而不是表单建模,您可以编写适用于表单之外的规则,并且您不必开发用于表达表单依赖关系的微型语言。
我目前正在构建一个 web 工具,它使用户能够生成字符串形式的选项包。对于 select 他想要的选项,他使用了一个具有不同输入(单选框、复选框)的表单,该表单是从 dictionary.json
生成的,该表单当前包含以下格式的所有可用选项及其代码(可能会更改) :
[
{
"id": 0001,
"title":"foo",
"type":"radio",
"options":[
{
"bar":"",
"foo":"489",
"foobar":"489+490"
}
]
},
{
"id": 0002,
"title":"something",
"type":"check",
"options":[
{
"everything":"M016",
"evenmore":"M139"
}
]
},
[...]
如您所见,它基本上是一个小型数据库。问题是选项相互依赖,所以如果 foo
是 foobar
它可能会确定 something
肯定是 evenmore
并且不能更改为 everything
. 我如何在 dictionary.json
中映射这些依赖项,以便生成的表单能够可靠地将由其他选择确定的选项变灰?
结构必须灵活,以便可以插入新的依赖项并可靠地生成新表单或根据它们验证现有输出。也可能有依赖于多个其他选项的选项。我想不出一种保存这些依赖关系的聪明方法,我想知道 JSON 是否适合这里的格式。
欢迎任何提示或想法。谢谢!
您可以尝试将每个选项保存为一个对象,该对象存储所有选项,如果该选项被 selected,这些选项将被排除。 因此,您的 JSON 可能如下所示:
[
{
"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": []
}
]
},
[...]
每次 select 编辑一个选项时,您都必须检查他们的排除列表并禁用特定字段的所有这些选项。
为了提高可用性,您可以检查一个字段只剩下一个选项,select 这个选项,然后禁用整个字段。
编辑:
此外,您可以为每个选项保存一个 isExcludedBy
字段。
id 0002
的 everything
选项将如下所示:
"isExcludedBy": [
"id": 0001,
"options": [
"foobar"
]
]
这有点多余,但根据您希望 UI 显示的内容,它可以为您节省一些计算时间。
可能的简单解决方案(回答您的问题):
// 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"]],
]
}
dependencies
由成对的 [path to option in options
暗示另一个选项, path to the implied option ]。
您可以直接从中创建一个 Map
数据结构(隐含的选项是键,隐含的是值)。
这假设一个选项只能暗示另一个选项(但它仍然允许选项依赖于多个其他选项)。
您当然可以像这样轻松扩展它:
[["0001", "foobar"], [["0002", "evenmore"], ["0003", "namaste"]]]
这意味着 "0001"/"foobar"
意味着 "0002"/"evenmore"
和 "0003"/"namaste"
。但也许是 YAGNI。 :)
解决此问题的一种方法是对您实际表达的域建模,并基于该域生成表单。比如,我们知道公寓有门牌号,门牌号,而船屋连门牌号都没有。
{
"dwelling": {
"type": "houseboat",
"latitude": null,
"longitude": null,
}
}
或
{
"dwelling": {
"type": "apartment",
"street": "Beech St.",
"street_number": 123,
"apartment_number": 207,
}
}
通过对域而不是表单建模,您可以编写适用于表单之外的规则,并且您不必开发用于表达表单依赖关系的微型语言。