Open bvaughn opened 9 years ago
I believe we can certainly support a large subset by clever use of custom validators, i.e. instead of writing form-js validation to match JSON Schema we can use custom validators (functions) to do all the complicated stuff.
Good point. I guess it's just a question of how much effort we want to put into it. :)
Tentatively assigning this one to @mohsen1 since he both seemed the most passionate about it and likely has the most experience. If you're too busy to pick it up, or if someone else really wants it, feel free to reassign. :)
I think this should be it's own module with it's own tests and issue tracker.
Up to you I suppose, so long as that wouldn't be making more work on ourselves or our users. (Ourselves to release another parallel module, and our users to know to include a 3rd module).
Ok, I'll keep it in this repo for now.
Shouldn't the convertor also produce the "view" object? I see in your example description of age
property was lost during conversion.
Hm, I would think the JSON schema only applied to validations, no? Doesn't seem like the view schema is all that related.
Description of what "age" property?
JSON Schema can have description
and title
fields
"age": {
"title": "Age",
"description": "Age in years",
"type": "integer"
Ah, I see what you're saying.
It's not immediately clear what the description field maps to in the view schema though. Is it the placeholder
text? Or the help
text?
I suppose we could pick a stance and have the JSON schema mapper create part of the view schema as well...but I think the primary focus should be validation.
I think we need to shape the view object from JSON Schema too. We can't just lose the details. I wish there was some documentation about how the validation and view objects should be structured.
There is also some features of JSON Schema that I'm not clear how it should be translated. For example anyOf
or allOf
For example for this schema:
{
"anyOf": [
{ "type": "string", "maxLength": 5 },
{ "type": "number", "minimum": 0 }
]
}
"100"
and 100
are both valid.
anyOf
, allOf
and oneOf
can of course be much more complicated.
I wish there was some documentation about how the validation and view objects should be structured.
There is documentation- in the form of interfaces (and tests). There will be more, in the form of HTML guides, once we're further along - but for now the interfaces are what we should all be coding to.
If you want to support anyOf
, allOf
, and oneOf
then that will likely involve implementing a couple of custom validator functions but our validation schema design is flexible enough for this to work fairly easily.
PS. If this mapper lives in the forms-js repo, it should be possible for these custom validator functions (e.g. any-of) to use the built-in validators like min/max.
A significant percentage of Forms JS users will likely prefer to use their pre-existing JSON schemas to validate forms. We should create a utility class that eats JSON schema and transforms it to the custom form-validation schema used by Forms JS.
For example, the following JSON schema:
Should be transformed into the following Forms JS validation schema:
It is likely that we will only support a subset of the JSON schema and so this issue should also result in documentation that clearly outlines what that subset is.