Open brettz9 opened 10 years ago
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.
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).
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.
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.
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:
window.EpicEditor
or $.fn.sceditor
)input_type
/wysiwyg
combination and no specific code editor is indicated for a given schema item) with:
input_type
(s) the editor supportswysiwyg
(false
being the default since not all languages would have a wysiwyg
possibility (though they might have a graphical/textual editing possibility))this
object, so that it can still call its own methods/properties:
afterInputReady()
(or if this is a new API, maybe getValue()
would be clearer)setValue()
destroy()
init()
method for any work to be done after plugin registration when an editor was created.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:
input_type
(html
, bbcode
, etc.)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.)
And I'm happy to get started on this soon if you'd be interested.
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.