XH 1.6: Editor Configuration as JSON

[cmb]

Hello Community,

how about standardizing the format for the editor configuration files (aka. inits) as JSON? Currently it's open to every editor integrator to choose a format that suits his needs. But all 3 currently available editors for CMSimple_XH use JS object literals anyway, so the step to JSON is merely a slightly more restrictive notation (besides for Codeeditors key-bindings; but I'm quite confident that I could work around that). The advantage: JSON can be easily parsed by PHP, so plugin authors might make dynamic modifications to the inits if necessary. Additionally one could imagine to introduce configuration defaults (similar to the language defaults) for an easier update without overwriting customizations (alternatively an update script could easily merge an old and a new configuration file). Even the currently used placeholders could be removed from the files altogether, and instead these options could be merged into the configuration.

Christoph

[svasti]

Sounds good. Especially for upgrading.

[manu]

Sounds reasonable. Never noticed any differences.
Restrictions might appear when one tries to json_decode into php.
regards
manu

[cmb]

Hi manu,

actually the delivered init files of tinyMCE are plain JSON. But that's not the case for CKEditor and Codeeditor, even if the are very close to JSON. However, other editors (there are none yet, but that may change) might use a completely different format, so restricting the specification to JSON could be helpful in the long run.

Christoph

[manu]

So what's the intention? To store the inits in akind of config files? How could nested objects/arrays be handled? Doesn't this burst off the functionality of the general config file handling?

[cmb]

IMO it's less error prone to have the inits as JSON, and to handle the insertion of special values by reading, json_decode(), changing the structure, and writing back the JSON json_encode()d string, instead of replacing place holders (e.g. %FILEBROWSER_CALLBACK%). Of course every editor developer could do that already.

But declaring JSON as the mandatory/recommended format for the init files has additionial benefits:

• Sometime in the future it would be possible to offer update scripts for the editor inits too. I've done something like this for the config and language files already, but editor inits are almost impossible to manage when handled as arbitrary strings. (BTW: stylesheets make the same difficulties, but perhaps even for these there's a solution)
• It would be possible for other plugins to make dynamic changes to the inits. Currently if such changes are necessary, the plugin developer typically offers a separate init file for his plugin.
• Those parts which should never be touched by the user (i.e. the placeholders), could be removed from the inits.
• The API documention/specification could be simplified: http://cmsimpleforum.com/viewtopic.php? ... =50#p24482
• The editor developer could offer a config form for the inits. Nested arrays/objects would have to be treated as strings for display, editing and submission, but could nonetheless be checked for syntactic validity before writing them back.

[Holger]

Hi Christoph,

just be back now, you know I had other things in mind the last days...

IMO it's less error prone to have the inits as JSON, and to handle the insertion of special values by reading, json_decode(), changing the structure, and writing back the JSON json_encode()d string, instead of replacing place holders (e.g. %FILEBROWSER_CALLBACK%). Of course every editor developer could do that already.

But json_encode() / json_decode() was introduced with PHP 5.2. So we need to offer core-functions until XH sticks on PHP4.

But I'm not sure if it's really less error prone to use JSON, if a user want to add a plugin to the editor (without some kind of config-form).

Sometime in the future it would be possible to offer update scripts for the editor inits too. I've done something like this for the config and language files already, but editor inits are almost impossible to manage when handled as arbitrary strings.

+1

It would be possible for other plugins to make dynamic changes to the inits. Currently if such changes are necessary, the plugin developer typically offers a separate init file for his plugin.

A plugin developer can pass a a configuration-string to editor_replace()...

The API documention/specification could be simplified: http://cmsimpleforum.com/viewtopic.php? ... =50#p24482

The editor developer could offer a config form for the inits. Nested arrays/objects would have to be treated as strings for display, editing and submission, but could nonetheless be checked for syntactic validity before writing them back.

+1

JSON might be the first step to a better editor-interface. But I can't see the real big advantage only just by changing to JSON.

But IMO the editor-configuration (I mean the activated features in the toolbar) should be made editor - independent. I'm aware about a lot of differences between TinyMCE and CKeditor. But at least for a minimum bunch of settings, like toolbars, it might be possible (and even there I'm not sure if it's an advantage to use JSON).
For example it would be possible to enable / disable the table-functions and so on...

Another way could be to offer more pre-defined inits then today .


Holger

[cmb]

Hi Holger,

The API documention/specification could be simplified: viewtopic.php?f=29&t=3994&st=0&sk=t&sd=a&start=50#p24482

Instead of writing

Typically this will be a string in JSON format enclosed in { }, that can contain %PLACEHOLDER%s, that will be substituted.

in the best case we could write:

This is a configuration array.

Of course no great simplification, but at least one could avoid the details of specifying that the outmost braces have to be used for the parameter; and the placeholders could be skipped completely, as these can easily be added to the config array by the editor (at least if they're not already there).

A plugin developer can pass a a configuration-string to editor_replace()...

But how to build this config string? Reading the free format file and string/preg replacing is IMO hard. If the init is guaranteed to be JSON, the plugin dev could json_decode() it, and then use simple PHP array access to modify it, before passing the value to init_editor()/editor_replace().

For example Calendar uses a particular stylesSet in its init of CKEditor:

Code: Select all

	stylesSet : [
    {name : 'red',             element : 'span', attributes : { 'class' : 'red'} },
    {name : 'big',             element : 'span', attributes : { 'class' : 'big'} },
    {name : 'small',           element : 'small' },
    {name : 'img left',        element : 'img', attributes : { 'class' : 'left'} },
    {name : 'img left under',  element : 'img', attributes : { 'class' : 'left_under'} },
    {name : 'img left2',       element : 'img', attributes : { 'class' : 'left2'} },
    {name : 'img right',       element : 'img', attributes : { 'class' : 'right'} },
    {name : 'img right under', element : 'img', attributes : { 'class' : 'right_under'} },
    ],

To dynamically add these to the general init is hard. On could do:

Code: Select all

preg_replace('/stylesSet\s*:\s*\[[^\]*]/s', '...', $init); 

But it's easy to make a mistake in the regex. But what if stylesSet is not defined in the init? Or even worse: it's commented out (line comments vs. a block comment).

It's much easier and less error prone to do:

Code: Select all

$init['stylesSet'] = $myStyles; 

But json_encode() / json_decode() was introduced with PHP 5.2. So we need to offer core-functions until XH sticks on PHP4.

Why not? JSON is a very simple format. A sufficient json_encode() is easy (I'm using a self-written one already in 2 plugins), and even json_decode() isn't too hard. Of course these functions are much slower than the native PHP alternatives, but they only have to be used as fallback for PHP < 5.2:

Code: Select all

if (!function_exists('json_decode') {
    require_once 'json.php';
} 

But IMO the editor-configuration (I mean the activated features in the toolbar) should be made editor - independent. I'm aware about a lot of differences between TinyMCE and CKeditor. But at least for a minimum bunch of settings, like toolbars, it might be possible (and even there I'm not sure if it's an advantage to use JSON).
For example it would be possible to enable / disable the table-functions and so on...

Another way could be to offer more pre-defined inits then today

At least some parts of the editor config might be standardized. But I wouldn't offer more pre-defined inits. Actually the toolbars do never fit the template, so one has to rearrange them to avoid wasting screen space.

BTW: Thinking about the toolbars and the default inits: currently we're using completely separated inits, just to have different toolbars. This could be changed to have a general init + an additional init for each toolbar.

Christoph

[Holger]

Hi Christoph,

to be clear: I'm not against JSON. It's good practise IMO. And having fallbacks for json_en(de)code() in the core will prevent inventing the wheel or duplicate code with every plugin.

But in the long run I wish to have more standardisation for the editor configuration because it's hard for a plugin developer to write compatible code for different editors... and much harder for a user to adjust the editor for his needs.

BTW: Thinking about the toolbars and the default inits: currently we're using completely separated inits, just to have different toolbars.

Hmm. in CKeditor removing parts from the toolbar results in changes of the plugins to load.

Anyway. AFAIK JSON is in progress for 1.6 and TinyMCE. I'll see how I can provide it for CKeditor4.

Holger

[cmb]

Hi Holger,

to be clear: I'm not against JSON. It's good practise IMO. And having fallbacks for json_en(de)code() in the core will prevent inventing the wheel or duplicate code with every plugin.

That's another good argument.

But in the long run I wish to have more standardisation for the editor configuration because it's hard for a plugin developer to write compatible code for different editors... and much harder for a user to adjust the editor for his needs.

I'm not against more standardization for the editor configuration. And it seem to me tinyMCE and CKEditor are the main candidates for editors in the long run. But we might have a look at other editors too (e.g. Aloha Editor seems to be an interesting candidate).

in CKeditor removing parts from the toolbar results in changes of the plugins to load.

That's the same with tinyMCE But at least some additional configuration might be put to separate files.

for CKeditor4.

Ah, you've noticed already!

Christoph