Decoupling string format editors from syntax highlighting

[brettz9]

I'd like to suggest decoupling the SCEditor, Epic Editor, and ACE Editor from the string formatting. Even if you wanted to reserve your own keywords which matched ACE Editor's, etc., it'd be nice to have a way to map these to say, CodeMirror.

[jdorn]

I like having

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

This format is in line with the other ones in the spec (e.g. "email", "uri", "date-time") in that it defines the structure of the string value. It sets limits on what strings are valid. The idea behind JSON Editor is to take these and other validation hints and use them to build a useful UI.

It would probably be better if ACE Editor, Epic Editor, and SCEditor were different editor classes and they used resolver functions instead of just being if/else blocks inside of the string editor. That would make make it much easier to add support for CodeMirror or others without touching the already bloated string editor source.

[brettz9]

Oh, I absolutely support what you're doing with "format"--I just didn't like the spec's name for it since as you say it has validation implications as well. Here, I was just asking for the code avoiding hard-coding a commitment to these particular editors, so yes, separate editor classes is exactly the kind of thing I was hoping for (unless you wanted to keep hard-coding accepting specific programming language formats, but let the handler differ).

[brettz9]

A compelling advantage of hard-coding the specific programming language formats is that one would not have to change one's JSON to switch editors, though one would have to maintain which languages were possible and make exceptions if a handler could not handle all of them.

[brettz9]

e.g., if CodeMirror expected "ecmascript" or "application/javascript", and Ace editor expected "javascript". Hard-coding the formats would also allow new editors to come along without baking in their own checks about the formats used by Ace editor or CodeMirror, and could just rely on your list of languages.

[brettz9]

I wanted to make a pull request, but thought I would first confer with you on a desired structure before going through with it. I wasn't sure whether you would like a custom API for code editors or just to treat them as an extension of the string editor (or that each inherit from an abstract code editor class).

In any case, in order to avoid baking in editor dependencies, I was hoping like to see specific code editors be allowed as plugins, where each included plugin file will:

1. Check to find any required libraries (e.g., window.EpicEditor or $.fn.sceditor)
2. If all required libraries are found, call a registration API (with registration order being significant in case multiple editors both support a given input_type/wysiwyg combination and no specific code editor is indicated for a given schema item) with:
   1. The input_type(s) the editor supports
   2. Whether the editor supports wysiwyg (false being the default since not all languages would have a wysiwyg possibility (though they might have a graphical/textual editing possibility))
   3. A callback object which contains its own methods, with each method to be supplied the this object, so that it can still call its own methods/properties:
      1. afterInputReady() (or if this is a new API, maybe getValue() would be clearer)
      2. setValue()
      3. destroy()
      4. Probably also an init() method for any work to be done after plugin registration when an editor was created.
3. Build its own empty JSONEditor.plugins.<editor name> object (since it is probably too difficult to try to abstract the editor options), or even easier, if code editors get their own API, just require the developer in the registration call to supply a name for the editor, and then create a blank JSONEditor.plugins.<editor name> object for them.

In addition to calling the above methods at the appropriate time, your afterInputReady() method can be modified depending on whether the schema item (or editor instance) hard-codes a particular code editor:

1. if yes, use the hard-coded code editor
2. if not, check a map (built up during plugin registration time) to detect whether the code editor can handle:
   1. the current input_type (html, bbcode, etc.)
   2. any schema item or editor indication that it must be wysiwyg or not wysiwyg

If wysiwyg or not wysiwyg is indicated (by schema item or editor instance), a code editor supporting both types can also decide to handle it differently (e.g., displaying the source code by default if wysiwyg is off, but allowing the user to switch manually to wysiwyg). Note that wysiwyg may be relevant for other types besides html, such as markdown, so that's why the above treats it as distinct from the type.

If this sounds good, let me know whether you would like a PR based on reimplementing the existing supported code editors as extensions of the string editor, or whether to design a new API for them. (And I may also look to create a plugin for CKEditor since SCEditor is stripping out spaces when I paste in formatted content.)

[brettz9]

And I'm happy to get started on this soon if you'd be interested.