Hi guys, just wondering is there a good reason for why the loading order of config specified in customConfig files is in reverse to what would make more sense and follow the concept of inheritance from generic to more specific?
Specifically, I tested with 2 config files being specific_config.js and generic_config.js with specific_config.js having customConfig=generic_config.js and customConfig=specific_config.js in the in-page config. I put font_names into both and found that what's defined in generic_config.js actually overrides specific_config.js rather than the other way round that would make more a lot more sense.
With the current loading order it's basically impossible to perform any kind of overriding in a cascading fasion as one is used to with css, inheritance, etc. The in-page config overrides what's defined in the customConfig, but within the custom config files themselves you are practically limited to 2 levels and without any overriding.
Would the CKEditor team consider reversing the loading order so that config defined in the file referenced using customConfig parameter is loaded first and then overriden with config specified directly in the file.
Good question. I believe that
Good question. I believe that this design decision was made during works on v3 and that's few years before I started, so I can't give you an answer. Will pass this question to Frederico Knabben.
In my opinion referencing one config file from another one does not make much sense in general. I remember that I was surprised when I learnt that you can load two config files (this is maximum AFAIK). I think that these cases should be solved in JavaScript where you can inherit between config objects as you wish. I don't even think that CKEditor's config should be kept in a separate file, because it's another file to load, another few ms to wait. Hence, more files make even less sense.
Therefore, if we ever change this behaviour, I would guess that we'll make it possible to load only one file, if anything.
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+
It makes sense
@Sheldmandu, what you're talking about makes sense. The way it has been developed is to "extend" the config object, while you expect instead "inheritance" to happen. Actually, you just expect it to happen in the same was in both the config files processing and the in-page config processing.
Btw, theoretically, there is no limits in the number of config files to be loaded. Still we never really designed it for this.
The whole point about customConfig (as it's name says) is (1) to load a custom configuration using the default config.js, (2) to make it possible to avoid config.js and point to a custom configuration file straight and (3) to avoid configuration files altogether.
While your request is valid, I doubt that we'll work on this at this stage. We'll be probably simplifying this feature with CKEditor 5.
Ofc, you may decide to send us a pull request at the CKEditor dev repo at GitHub with the fix for it. It would be definitely welcome ;)
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Thanks for the feedback
Hi guys, thanks for the feedback. Extending vs Inheriting is a good way to describe the different approaches. I think inheritance makes more sense because it's more natural for anyone who's done programming or CSS and more consistent with the way the in-page config overrides the customConfig.
If you're going to simplify the customConfig feature in CKEditor 5, especially by removing the ability to chain customConfig files there isn't really any point for me to rewrite the loading procedure. Btw, there's currently no limit to the number of customConfig files you can chain... this handled in the loadConfig function.
I actually think it makes sense to keep the the chaining functionality (either through extension or inheritance) since it's already there and let the developers using CKEditor in their application decide if and how they want to use the chaining capability. They just need to be aware of the benefits and drawbacks.
To give you an example, in my situation I've actually developed a Winforms control that use CKEditor to provide WYSIWYG HTML editing capability for a desktop application and in this instance it would be really handy to have config file extension or preferably inheritance as latency is not an issue and the benefits of being able to split out common config into a separate file outweigh the drawbacks of increasing the loading time by a milliseconds.
The fact that the feature
The fact that the feature exists should not be a reason to keep it in CKEditor 5, which will be designed from scratch. If there were no other solution for this problem, then that would be a reason. But since it's basically a JavaScript one can do anything - even with files. For example you can build an inheritance using AMD and compose a config object (which you'll pass to CKEditor creator method) using Require.JS. Or you can just include the files using <script> tags. This will let you (if it was important in your case) to concatenate all this JS for production. CKEditor must become less opinionated - especially where it does not necessarily need to do something.
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+