Matthew Moisen
Matthew Moisen

Reputation: 18289

Adding properties to fields in json-schema to tightly couple the schema with a web UI

My application will be receiving a large json payload from an upstream system. This upsteam system is essentially a UI that will be collecting business requirements from a user, format those questions and facts into a json payload, and transmit the json to my application, which will validate it against a schema defined by the json-schema standard. The conundrum is that this upstream system is being built by a different team who doesn't necessarily understand all of the business requirements that need to be captured.

Take the following schema:

schema = {
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title":"Requirements",
    "description": "A Business Requirements Payload",
    "type": "object",
    "properties": {
        "full_name": {
            "type": "string"
        },
        "sex": {
            "enum": ["m", "f"]
        },
        "age": {
            "type": "number"
        },
        "consents": {
            "type": "boolean"
        }
    },
    "required": ["full_name", "sex", "age", "consents"],
    "additionalProperties": False
}

Assume that the upstream system has no idea what a full_name, sex, or age was. Currently, I am having meetings explaining the nature of every field/question/fact that I require, default values that should show up on the UI, accompanying text labels that should show up to each field, and etc.

In brainstorming a mechanism to make this easier for everyone, I thought of tightly coupling the json-schema I am creating to the UI that the upstream system is building. What if I include these details inside of the json-schema itself, hand the json-schema to the upstream system, and let the UI team generate the UI with the accompanying text labels, default values, and etc?

For example, the full_name and sex fields could instead be described like this:

    "full_name": {
        "type": "string",
        "default": "\"John Smith\"",
        "label": "Full Name",
        "text": "Please include your full name.",
        "description": "This field will be the primary key in the database"
    },
    "sex": {
        "enum": ["m", "f"],
        "default": "m",
        "enum_labels": ["Male", "Female"],
        "label": "Sex",
        "text": "Please include your sex.",
        "description": "We want to run analytics on this field"
    }

The UI team and I could come to an agreement on certain things:

Here are some negatives to this approach:

It it appropriate to tightly couple a json-schema with a UI, and if it is, is there anything wrong with adding properties to the json-schema like I have described in order to accomplish this?

*I just stumbled across jsonform which is pretty much what I desire, but this question still applies to jsonform as well as a custom parser.

Upvotes: 0

Views: 2263

Answers (1)

suncat100
suncat100

Reputation: 2194

Just to be certain, you are aware there is an optional form object which is used to structure the form output? It allows custom grouping, custom ordering, conditional fields and more ... https://github.com/joshfire/jsonform/wiki#fields

If your default schema object is satisfactory for both the form layout, as well as how the data object gets stored, then nothing wrong with sticking to the schema for layout of the form.

I am not sure if this answers your question, but the question is slightly unclear to me. Basically yes you can stick to the main schema, but if that is not sufficient for the form layout, you can populate the form object.

Upvotes: 1

Related Questions