How does Angular Schema Form work?
Why does Angular Schema Form have both json form and separate json schema? It looks like some properties in a form might be in a schema and vice versa. For example, in a simple example on schemaform.io, we have a form:
[
"name",
"email",
{
"key": "comment",
"type": "textarea",
"placeholder": "Make a comment"
},
{
"type": "submit",
"style": "btn-info",
"title": "OK"
}
]
And the diagram is like:
{
"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"
]
}
It seems that in a property email
in a schema title
, both and description
can also be in a form definition, as in a schema. Can anyone explain the meaning of both the form and the schema and why they are separate?
source to share
JSON schema
JSON Schema is an IETF standard (linked to the JSON-Schema docs )
JSON Schema Form org (which ASF is part of) cannot independently make changes to the JSON Schema standard. The JSON schema is only for the model / validation / definition of hypermedia at this point.
The JSON Schema Form org is in direct discussion with the JSON Schema org and now I am a part of that organization too as we end up defining a JSON Schema UI standard that can end up as nothing from a simple method to avoid property collisions in future or more detailed standard.
Currently, the way Angular Form Schema is rendered from jsonForm creates some confusion with similar terms that cannot be used in the same way between formats and variations in a format such as using dot notation keys or readOnly vs readonly.
User interface diagram
The need for many organizations using JSON Schema is to provide a UI to edit the data format defined by the schema, so the UI schema dictates how the model should be displayed. This allows schema values to be overridden, so most, if not all of the values in the schema can be changed, and it also adds additional types based on templates defined within the framework (which may change to a different term, such as widgets in the future).
The UI schema also uses arrays to ensure that the order of the fields is as expected, providing the ability to define only a key to create a form field only from the data found in the JSON schema definition. You can also use wildcards and shortly ellipsis to create form elements without even using keys, if no overrides are required at all.
Separation of concerns
The reason for not trying to combine the two is because of separation of concerns, the UI schema essentially acts like a type of view controller. Many enterprise applications will use the same data in many different views, for example when an administrator has more access to edit data than a typical employee. It doesn't make sense to duplicate the data model every time, just the view.
This may seem overkill for a very simple form, but you never know when requirements will expand and new functionality will be added, which will require a new presentation of the data.
It is also often necessary to maintain state information in the browser with attributes defined in a form that is not found in the model.
Disclosure: I am the maintainer of the Angular schema form at the time of writing.
source to share