为什么Angular Schema Form同时具有json形式和json模式?似乎表单中的某些属性可能在模式中,反之亦然。例如,在schemaform.io网站上的简单示例中,我们的格式为:
[
"name",
"email",
{
"key": "comment",
"type": "textarea",
"placeholder": "Make a comment"
},
{
"type": "submit",
"style": "btn-info",
"title": "OK"
}
]
架构为:
{
"type": "object",
"title": "Comment",
"properties": {
"name": {
"title": "Name",
"type": "string"
},
"email": {
"title": "Email",
"type": "string",
"pattern": "^\\S+@\\S+$",
"description": "Email will be used for evil."
},
"comment": {
"title": "Comment",
"type": "string",
"maxLength": 20,
"validationMessage": "Don't be greedy!"
}
},
"required": [
"name",
"email",
"comment"
]
}
似乎在模式的email
属性中,title
和description
也可以在模式中的表单定义中。有人可以解释形式和架构的含义以及它们分开的原因吗?
答案 0 :(得分:0)
JSON架构
JSON Schema是IETF标准(从JSON-Schema docs链接到
)JSON Schema Form org(ASF是其中的一部分)无法自行更改JSON Schema标准。在此阶段,JSON Schema仅设计为模型/验证/超媒体定义格式。
JSON Schema Form org与JSON Schema org直接讨论,我现在也是该组织的一部分,因为我们最终还要定义 JSON Schema UI 标准,这可能会结束从简单的方法来确保未来不会发生财产冲突或更详细的标准。
目前,Angular Schema Form从jsonForm演变的方式确实会产生一些混淆,这些术语在格式和格式变体之间不能以相同的方式使用,例如使用点表示法或readOnly vs readonly。
UI架构
许多使用JSON Schema的组织需要提供一个用于编辑模式定义的数据格式的UI,因此UI模式定义了模型的呈现方式。它允许覆盖模式值,因此可以更改模式中的大多数(如果不是全部)值,还可以基于框架中定义的模板添加其他类型(可能会在未来更改为不同的术语,如小部件)。
UI Schema还使用数组来确保字段的排序符合预期,同时提供仅定义密钥的功能,以便仅从JSON模式定义中找到的数据生成表单字段。如果根本不需要覆盖,您也可以使用通配符和很快省略号来生成表单元素,甚至不使用键。
关注点分离
不尝试将两者结合起来的原因是为了分离关注点,UI Schema本质上充当一种视图控制器。许多企业应用程序将在许多不同的视图中使用相同的数据,例如,当管理员具有比常规员工更多的编辑数据访问权限时。每次复制数据模型没有意义,只有视图。
对于一个非常基本的表单来说,这似乎有些过分,但您永远不知道何时会扩展需求并添加新功能以使数据的新视图成为必需。
通常还需要在浏览器中支持状态信息,其中包含在模型中定义的属性中未找到的属性。
披露:在撰写本文时,我是Angular Schema Form的维护者。