Configuration

This is a proposal for the new configuration system to be developed for FCKeditor 3.0.

Current State

In version 2.x, the configuration of an editor instance comes from the following sources:

• The fckconfig.js file: this is the default configuration file. I leaves outside the editor compressed code, so users can easily change it to their needs.

• Custom .js configuration file: optionally, developers can use the "CustomConfigurationsPath" setting to makes the editor load another JavaScript file that may override the settings from the fckconfig.js file.

• Inline page configurations: those are configurations coming from the page were the editor is being created. All configurations are placed in a hidden field using a URL style format (param1=value1&param2=value2&...).

Current Problems

No compression

The default configurations are not compressed alongside with the rest of the code. Even if no changes are made in the settings, a separated file must be downloaded with all configurations.

No in-code documentation

To limit the size of the downloaded file, no comments are added in the fckconfig.js file, making it difficult for developers to understand the meaning and the usage of each setting.

Upgrade issues

Any change in the fckconfig.js file must be remembered on upgrades, and it is quite easy to forget them, in the middle of all those settings with default values.

No Arrays of Objects from in-page configurations

There is no way to pass arrays or objects from the configurations set in the page where the editor is created. We are limited to Booleans, Strings and Numbers.

Proposal

Compress default configurations

A new file called "fckconfig_default.js" would be created in the root of the package. This file would have all possible settings of FCKeditor with their default values.

The code format would also suffer changes. The object block notation should be used instead:

FCKConfig =
{

// The following setting indicates that the fckconfig.js must be
// loaded after this file.
CustomConfigurationsPath : BASE_PATH + 'fckconfig.js',

// This is a setting of FCKeditor. Note that now every setting should
// be well commented.
// A String with some value.
Setting1 : 'Value',

// A Boolean setting.
Setting2 : true,

// A Number setting.
Setting3 : 10

...

} ;

Note that the FCKConfig object has not been declared with "var". This will be done before loading this file.

As this configuration file will be compressed, we can place as much comments as we can in this file.

Also, note that the CustomConfigurationsPath is used to point the editor to still load the fckconfig.js file. In this way, setting it to '' and rebuilding the compressed file, a developer could avoid loading that file. Another way to avoid loading the fckconfig.js is by setting CustomConfigurationsPath to '' or point to another file, inline in the page.

Another note... the FCKConfig object should not anymore be used to hold base values to be used in the configuration itself. So, instead of FCKConfig.BasePath, like we use today, we should use constant style variables (BASE_PATH in the above sample).

Avoid method calls

Today we are using some methods to set some configurations, like FCKConfig.ProtectedSource.Add() and FCKConfig.!Plugins.Add(). We should now avoid using methods in the config file. Those methods could be replaced with arrays. Something like this:

FCKConfig =
{

ProtectedSource : 
{
	/<%[\s\S]*?%>/g,
	/<\?[\s\S]*?\?>/g,
	/(<asp:[^\>]+>[\s|\S]*?<\/asp:[^\>]+>)|(<asp:[^\>]+\/>)/gi
},

ResetPlugins = true,

Plugins :
{
	BASE_PATH + 'plugins/autogrow',
	BASE_PATH + 'plugins/myplugin'
}
} ;

Thing to note is that the above arrays would not simply set the ProtectedSource and Plugins values, but will add the defined entries to the final arrays. So, if we have the main configuration file and the custom config file defining entries for those values, both arrays will be combined and the final one will have all defined values.

There are also cases where developers want to override the plugins list, for example, defined in the main config file with its custom ones. So, instead of combining the arrays, the new one should replace the older. For those cases, we could create new options, like the above ResetPlugins, to indicate that we want the Plugins array to be cleared when loading the configuration file. Other options would also be available, like ResetProtectedSource and so on.

JSON for inline configurations

To make it possible to developers to set any king of configuration in the editor, inline in the page where it is created, we should use a transportation format rich enough to carry arrays and objects, other than the basic JavaScript types.

JSON (http://www.json.org) is the natural choice for it, being it a well know and diffuse system, other than the performance advantages it offer.

---