Allowing "format" designations via JSONPath expressions

[brettz9]

As per discussion in issue #150 , there are a number of cases where one wishes to associate specific styling with certain structures. While one can use "format" for this, even though it is part of the spec drafts, I find the term and usage of "format" problematic for two reasons:

1. While JSON Schema may not impose validation on whether something is a URL, there is at least a semantic/structural connotation that the item is a URL--this is quite different from a mere formatting hint. In my opinion, it is very appropriate to indicate inline with the schema that something is a URL, but "format" is an unfortunate choice, imo, even if it may also have formatting connotations.
2. More relevant to JSON Editor itself, analogous to avoiding the problems faced by HTML with inline styling, it would be great if genuine formats (mere stylistic choices) could be associated to their objects by something like JSONPath in the equivalent of a "head" of the schema, if not entirely out of the schema and supplied as options to the editor.

[jdorn]

I agree that overloading format to include stylistic options isn't the best practice. The only string format in my opinion that does this though is textarea. The rest of the formats are similar to URL. If the format is set to html, that implies the value should be valid HTML. It's not just a stylistic thing.

I'm fine with moving textarea out of the format keyword. Maybe have a newlines: true attribute or something.

Also, the current use of format for arrays and objects (e.g. tab, table, etc.) is not great since these are really just stylistic formatting hints. I'm fine with moving these to a layout property or something.

As far as JSONPath support, are you thinking something like this?

{
  "type": "object",
  "properties": {
    "name": {"type": "string"}
  },
  "style": {
    "#/name": {"color": "blue"}
  }
}

[brettz9]

Yes, exactly my thought re: the tab/table, and as per my comment #157 (comment) just now, I do definitely agree with using "format" for those with validation consequences, even if the spec's usage of the term "format" suggests the opposite usage. (FYI, I have filed a request at json-schema/json-schema/issues/135 to this effect.)

As far as styling, I think ideally, CSS would be used, with the editor perhaps providing IDs derived from the current JSONPath of the JSON being iterated or classes derived from the format of the object. But what I was intending was more the ability within JSON (as opposed to JSON Schema) that a specific array should be rendered as a table, but without putting that inline... e.g., using pseudo-code as I am rusty on my JSONPath, {styles: {"/obj1/array2[3]": "table"}, data: {obj1: {array2: [3, 4, ['Show me as a table']]}}}

[brettz9]

Updated my last post, though besides allowing for a JSON format which defined the mapping, it could also be supplied within configuration upon JSONEditor instantiation. (Gotta run at the moment)

[brettz9]

But I don't think any styling at all needs to be in the schema (except for using, as you do, the "format"s that convey validation as hooks for certain structures)...

[Reggino]

I agree with you guys here, but i think the style should not be part of the schema (as proposed), but rather an extra option to pass to json-editor when constructing it.

In a bit similar, awesome but outdated & abandoned jsonform (https://github.com/joshfire/jsonform) project, the authors decided to completely split JSON Schema from presentation-logic, see https://github.com/joshfire/jsonform/wiki#controlling-the-layout-of-the-form. I personally very much like the idea of explicitly separating this stuff. Inspired by this project, i can think of the following "style" options that would give a more fine-grained control over the generated form without having to change the schema. Useful style options seem to me:

• htmlClass
• type (to overload the default input type e.g select vs radios and input vs textarea vs wysiwyg vs password)
• disabled
• readonly
• placeholder
• title
• titleMap (for enums)

That would make the pseudo-code look like:
{styles: {"/user/login": {"readonly": true}, "/user/password": {"type": "password"}}}

[Reggino]

(updated comment to be a bit more on topic)

[jdorn]

I really like having everything needed to render the form being in a single JSON Schema like it is now. But I also know some people would prefer a bigger separation of schema and presentation. What about making these 2 ways of using JSON Editor equivalent:

Everything within the JSON Schema:

var editor = new JSONEditor(element,{
  schema: {
    "type": "object",
    "options": {
      "layout": "grid"
    },
    "properties": {
      "text": {
        "type": "string",
        "multiline": true
      }
    }
  }
});

Separation of schema and presentation:

var editor = new JSONEditor(element,{
  schema: {
    "type": "object",
    "properties": {
      "text": {
        "type": "string"
      }
    }
  },
  options: {
    "root": {
      "layout": "grid"
    },
    "root.text": {
      "multiline": true
    }
  }
});

I feel like this would solve both use cases. Any thoughts?

[Reggino]

👍

The "type" styling option in my example would conflict with the schema property type, so we would need another name for that, lets say "inputType". That would make sample code:

{
    "schema": {
        "type": "object",
        "$schema": "http://json-schema.org/draft-04/schema",
        "properties": {
            "gender": {
                "type": "string",
                "enum": ["M", "F"]
            },
            "username": {
                "type": "string"
            }
        },
        "required": ["gender"]
    },
    "options": {
        "root.gender": {
            "inputType": "radio",
            "titleMap":{
                "M": "Male",
                "F": "Female"
            }
        },
        "root.username": {
            "readonly": true
        }
    }
}

Something like this?

Style options

htmlClass {string} - to be added to the input-container
inputType {string} - E.g. "select" or "radio" for properties with enums. May be "password", "textarea" or "editor" for strings.
titleMap {object} - Key - value store for enums to indicate the representation in the form.
disabled {boolean} - Mark the input as "disabled"
readonly {boolean} - Mark the input as "readonly"
placeholder {string} - The placeholder to use for the input
( plain {boolean} - strip any inline style ) ?

[jdorn]

readOnly is already part of the JSON Schema spec (the HyperSchema one if I remember correctly)
What's the difference between readonly and disabled?

I think password should still be part of format. The others are fine.

I think titleMap could be confused with the title keyword in JSON Schema. Maybe enumDisplay or enumTitles would be a better name.

[Reggino]

Agreed. readonly and disabled would both make the field uneditable, but disabled would not send the data to server when the form is submitted.

[brettz9]

Will be out of touch for a day or two and haven't read specific options carefully, but yes, this looks exactly like what I was hoping to see. Maybe "options" ought to be renamed to "style" or the like though to avoid confusion that there are other (non-scopable) options?

Just to reiterate my point that I hope that IDs (based on the current path) and especially classes (based on the format and current style-type options) may be generated and used wherever possible to allow most stylistic control to be given to CSS so designers can handle everything in one familiar place.

Of course, in some cases, the HTML itself may need to be altered, but a lot might possibly be handleable by CSS (even for changing divs to display: table-row or whatever). Of course, providing a default stylesheet would be important.

[Reggino]

What about form over options / style ? So you would get:

{
    "schema": {...},
    "form": {...}
}

You would have a clear separation of "schema" and "render instructions". (where internally form is applied over schema)

And may we should drop the "root." prefix in every key in form. If somebody really wants to apply an option to the root, an empty string could be used as key?