Add the following custom editors in addition to table:

• textarea

The HTML5 range input looks terrible and doesn't display the value anywhere.

Replace this with a custom range input, maybe theme specific.

Support definitions and $ref

http://json-schema.org/latest/json-schema-validation.html#anchor94

{
    "type": "array",
    "items": { "$ref": "#/definitions/positiveInteger" },
    "definitions": {
        "positiveInteger": {
            "type": "integer",
            "minimum": 0,
            "exclusiveMinimum": true
        }
    }
}

http://purecss.io/

Support minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf schema keywords.

Also, now that most of the JSON Schema spec is supported, the documentation should be updated to just list the schema keywords we don't support or only partially support.

Right now, $ref only works when referencing local schemas defined in a definitions block. $ref should also be able to load schemas from external urls.

{
  "description": "User's location",
  "$ref": "http://json-schema.org/geo"
}

Support template engines other than swig. Here's an example for Handlebars:

// Default value
$.jsoneditor.template = swig;

// Handlebars supports the same API as swig
$.jsoneditor.template = Handlebars;

// Mustache needs a small wrapper object to support swig's api
$.jsoneditor.template = {
  compile: function(template) {
    return function(view) {
      return Mustache.render(template, view);
    }
  }
};

Add ability in the schema to set an editor of type object to be collapsed by default. Maybe this should be abstracted to support arbitrary editor options.

{
  "type": "object",
  "options": {
    "collapsed": true
  },
  "properties": {

  }
}

show/hide the "add/remove property" links for an object when minProperties or maxProperties is hit.

JSON Editor's use of the id keyword is not consistent with the specification.

Using id as a display title

JSON Editor will use the id field as a display title if title is not set. This doesn't make sense with the specification since ids are urls or url fragments that aren't user friendly to display. Instead, only title and key should be used as display names.

Using id in template variable paths

This currently breaks when used with real world id fields:

{
    "type": "array",
    "items": {
        "id": "http://example.com/item-schema",
        "type": "object",
        "properties": {
            "key1": {
                "type": "string"
            },
            "key2": {
                "type": "string",
                "template": "{{key1}}",
                "vars": {
                    "key1": "http://example.com/item-schema.key1"
                }
            }
        }
    }
}

This will currently break since JSON Editor splits the template variable path on the period character, so the first part would be http://example, which isn't a valid id in the schema.

A better approach would be to separate the id from the path when declaring template variables.

{
  "vars": {
    "key1": ["http://example.com/item-schema","key"],
    "key2": ["#","path.to.key"]
  }
}

This format can maintain backwards compatibility with the current one, which is always nice.

This should re-purpose the type switcher currently used for union types.

The tough part is going to be coming up with display names to put in the drop down. This is the order of preference

• The title property if set
• The description property if set (maybe only the first N characters)
• The format property if set
• The type property if set
• The stringified value if the length is less than 50? characters. May want to use a custom stringify that only picks important properties.
• The word "type"

If more than one select option is going to have the same display text, add an incrementing number to the end of each (e.g. "string 1", "string 2").

If minimum is not a multiple of multipleOf, set minimum to the next highest multiple.
If maximum is not a multiple of multipleOf, set maximum to the next lowest multiple.
Set step parameter of range input to multipleOf.

Handle error conditions for minimum>=maximum

The following comment should be at the top of the minified dist file. It has license and version info.

/*! JSON Editor v0.2.7 - JSON Schema -> HTML Editor
 * By Jeremy Dorn - https://github.com/jdorn/json-editor/
 * Released under the MIT license
 *
 * Date: 2013-12-24
 */

Right now, if you want to use a theme other than bootstrap2, you have to pass it in every time you instantiate an editor.

The most common use case would be all editors on the page using a single theme, so it makes more sense to set this globally, the way the template it set.

$.jsoneditor.theme = 'jqueryui';

Can implement this several ways:

Make the existing table editor able to handle objects as well as arrays.

{
  "type": "object",
  "editor": "table"
}

Make the object editor look for a format property.

{
  "type": "object",
  "format": "table"
}

Add an editor option.

{
  "type": "object",
  "options": {
    "table": true
  }
}

My first preference would be to re-use the table editor so objects are handled the same way as arrays.

Editor

These are methods an editor should implement

• build() - should build the editor html
• getDefault()
• setValue(value) - set the editor's value
• getValue() - get the editor's cached value
• refreshValue() - force a refresh of the editor's value by recalculating from the underlying DOM (e.g. get the value of the <input> element)
• destroy() - clean up memory
• isValid(callback)
• getChildEditors()

Themes

These are the methods a theme should implement

• getFormInputLabel(text)
• getCheckboxLabel(text)
• getHeader(text)
• getCheckbox()
• getSelectInput(options)
• getTextareaInput()
• getRangeInput(min,max,step)
• getFormInputField(type)
• afterInputReady(input)
• getFormControl(label, input, description)
• getIndentedPanel()
• getChildEditorHolder()
• getDescription(text)
• getCheckboxDescription(text)
• getFormInputDescription(text)
• getHeaderButtonHolder()
• getButtonHolder()
• getButton(text)
• setButtonText(button, text)
• getTable()
• getTableRow()
• getTableHead()
• getTableBody()
• getTableHeaderCell(),
• getTableCell()

Property dependencies should just affect the required status of child editors.

Schema dependencies should be dealt with the same way as allOf.

Toggling the table editor would show/hide the table tag.

This should also support the collapsed editor option.

Move validation logic to it's own class.

$.jsoneditor.Validator = Class.extend({
  init: function(schema) {

  },
  validate: function(value) {
    var errors = [];

    errors.push({
      path: "person.name.fname",
      property: "minLength",
      message: "Must be at least 4 characters long"
    });

    return errors;
  }
});

The Validator class should cache validation results since it may be used extensively internally.

Here is what needs to be added to support JSON Schema V3 in addition to the already supported V4:

• required boolean attribute
• any type
• union types with schemas in addition to primitive types
• disallow
• divisibleBy
• extends

description should add a tooltip to the field.

default should pre-fill the field.

Add a resolver function that takes a schema and returns the editor to use. Have an easy way to extend this function.

First pass:

$.jsoneditor.resolvers = [
  function(schema) {
    // Use the 'type' property
    return schema.type;
  }
];

// Add your own resolver to the front of the list
$.jsoneditor.resolvers.unshift(function(schema) {
  if(schema.type == "array" && schema.format == "table") {
    return "table";
  }
});

If the editor property of a schema is set, use that. Otherwise, loop through the resolvers until one returns a valid value. If none of them return a valid value, throw an exception.

Have the core and each editor in a separate source file. Concatenate them together with grunt and produce a minified version.

This should improve the workflow.

We should add built-in support for popular template engines:

• mustache
• handlebars
• underscore
• EJS
• swig
• hogan
• markup

Use the following pattern:

$.jsoneditor.templates = {};

$.jsoneditor.templates.swig = function() {
  if(!window.swig) return false;

  return swig;
};

$.jsoneditor.templates.mustache = function() {
  if(!window.Mustache) return false;

  return function(template) {
    return function(context) {
      return Mustache.render(template, context);
    }
  }
};

// ...

Then, set $.jsoneditor.template to the first one that doesn't evaluate to false.

A user should be able to set the template engine at any point by doing:

// Included template engine
$.jsoneditor.template = "mustache";

// Custom template engine
$.jsoneditor.template = function(template) {
  return function(context) {
    MyTemplateEngine.render(template, context);
  }
})

If additionalProperties is not false, include an add property button that pops up a text input where you enter a property name.

If the property already is defined, show an error.

• If the property matches anything in patternProperties, use that as the schema.
• Else if additionalProperties is a schema, use that.
• Else use an empty schema.

The add property button should be hidden when/if minProperties is reached.

The behavior of the remove property links needs to change as well.

• If the property is enumerated in properties, it should collapse the field like it currently does.
• Else, the editor should be removed entirely.

Basically recursively merge the schemas in allOf and extends with the main schema before building the editor.

{
  "type": "object",
  "allOf": [
    {
      "properties": {
        "key1": {
          "type": "string"
        }
      },
      "required": ["key1"]
    },
    {
      "properties": {
        "key2": {
          "type": "string"
        }
      },
      "required": ["key2"]
    }
  ]
}

Should produce the following after it's expanded:

{
  "type": "object",
  "properties": {
    "key1": {
      "type": "string"
    },
    "key2": {
      "type": "string"
    }
  },
  "required": ["key1","key2"]
}

If items is an array, array elements 0 through items.length should validate against its respective schema.

• If additionalItems is set to false, set minItems to Math.min(minItems, items.length).
• Else if additionalItems is true or not set, all additional items should use an empty schema.
• Else all additional items should use the additionalItems schema.

You can pass in the theme to the initial options hash, but there is no way to pass in a templating engine.

$("#editor").jsoneditor({
  schema: {},
  template: "mustache"
});

This should take precedence over $.jsoneditor.template when set.

Add a $.fn.jsoneditor option to control what css framework the editor should be styled with. Try to include the following out of the box:

• html
• bootstrap3
• bootstrap2 (default)
• jqueryui
• jquerymobile
• foundation5
• foundation4

Skins should be flexible enough so that a user can create a custom one themselves. I'm thinking something like:

$.jsoneditor.skins.bootstrap2 = {
  getFormInput: function(type) {
    return $("<input type='"+type+"'>");
  },
  composeFormControl: function(div, label, input) {
    div.append(label);
    div.append(input);
  }
  //...
};

The required keyword lists the specific properties of an object that must be set. Currently, all object properties are always set, so validating against this doesn't make any sense. To add support for this keyword, we can do one or both of the following:

1. Change the meaning of required to mean not-empty. This means a blank string will fail. This will be inconsistent with the specification, but more inline with other implementations and common usage. I think this should be the default behavior and have an option to use the spec definition of required instead.
2. Add a way to remove non-required properties from objects. This will open the door to supporting other schema keywords additionalProperties, patternProperties, maxProperties, and minProperties.

A potential UI for removing properties could be something like this:

The maxlength and pattern input attributes should be used.

For minLength, if no pattern is specified, the input pattern should be set to .{minLength,}. Otherwise, just rely on validation and error messages.

minItems and maxItems:

• Hide the "add" button when the array has maxItems.
• Hide the "delete" buttons when the array has minItems.
• Default the array to minItems length.

A simple template engine should be included as a fallback.

It should only support the most basic macro replacements:

This is a {{macro}} replacement.

It's currently possible to enter data in the editor that doesn't validate against the schema. For example, entering a string value that doesn't match the required pattern.

There should be a way to check if the value is valid without requiring a separate JSON Schema validator. For example:

$("#editor_holder").jsoneditor('validate',function(errors) {
  console.log(errors);
});

errors would be an object where the keys are the paths and the values are error messages. Here is an exmaple:

{
  "root.age": "Must be between 18 and 99",
  "root.pets.0.name": "Doesn't match required pattern ^[a-z]{5,}$"
}

If the data validates against the schema, then errors will be undefined in the callback.

There should be an "Edit JSON" button for object and array editors that opens up a textarea where the user can edit the raw JSON value.

1. on change, run validation and cache the result
2. Add theme methods for getting error messages, styling inputs, etc.
3. add a showValidationErrors method for each editor which takes the validation result. If the editor doesn't have any errors in this array, it should remove all errors messages and error styling.
4. Objects and arrays should pass the error array to child editors.

According to the specification, the keyword type can be either a string or array of strings. Right now we only support the string variant.

This will require adding a new multiple editor and changing the type resolver function to use this in case of an array.

Mockup of the UI:

Arrays of numbers, arrays of arrays, etc.

At least on Chrome, when using , the value isn't displayed anywhere, so there is no way to tell what it is set at without looking at the outputted json.

The format keyword should change which HTML input type is used. For example:

{
  "type": "string",
  "format": "email"
}

This should still use the string editor, but should do <input type='email'> instead of the default text.

We should support the following formats:

• color
• date
• datetime
• datetime-local
• email
• month
• tel
• time
• url
• week
• range

To make the "range" type work, we also need to support the minimum and maximum JSON schema keywords.

{
  "type": "integer",
  "format": "range",
  "minimum": 20,
  "maximum": 40
}

<input type='range' min="20" max="40">