Opened 14 years ago

Last modified 14 years ago

#5998 new Task

Sample config.js file (config.sample.js perhaps)

Reported by: Vytenis Urbonavičius Owned by:
Priority: Normal Milestone:
Component: General Version: 3.3.1
Keywords: Discussion Cc:

Description

It is sometimes very confortible to have a prepared config file where You could see all the available configuration (commented out) and its documentation without having to go online and search what configuration parts are worth to be added to some particular project (it takes less time to go through config text file).

I have made such sample configuration file and would like to suggest to add it to the project. It is based on the official documentation and at the moment - up to date. In the first usage examples I have placed default values instead of writting them seperately.

Attachments (1)

config.js (34.5 KB) - added by Vytenis Urbonavičius 14 years ago.
Sample config file

Download all attachments as: .zip

Change History (12)

Changed 14 years ago by Vytenis Urbonavičius

Attachment: config.js added

Sample config file

comment:1 Changed 14 years ago by Charlie

Could use a little cleaning up and re-ordering...but cool

comment:2 Changed 14 years ago by Vytenis Urbonavičius

It would be great if You could write particular things that should be fixed.

comment:3 Changed 14 years ago by Charlie

Sorry should have been more specific. For me, it's to the point where it's hard to navigate. I think it would be more helpful if the following ideas were utilized:

1) Keep similar items together (You did this already)

2) Include plugin settings noting what plugin they relate to: I.E. i didn't see linkShowAdvancedTab.

3) Order it in such a way that people are likely to find what they want fast. There's no reason the width setting should be at the bottom while blockedKeystrokes is at the top

4) Use headings to seperate sections, i.e. General Settings, Style Settings, Plugin Settings, SCAYT settings, ouput settings, etc. Use some of those big fancy ASCII dividers people always use, like below or something that will get noticed: /

SECTION

*/

5) Consistant style... is it CKEDITOR.config.aaa or just config.aaa? Do you specify what the default behavior/value is? How many examples do we really need for each? For instance, I don't know if you're giving me an example of Protected source notation or if that's the defaults. Defaults can serve as examples, they just need to be notated so people aren't double defining things they don't have to.

6) Minor formatting, make sure tabs are consistant and all that stuff.


I know that's a lot of crap, but what you made is really REALLY helpful to people. I bet they will put it in, but it would have to be very carefully made and organized. (Look at configs like PHPBB or similar and how nicely and succinctly they format everything). Otherwise people will get fed up with searching and keep asking in the forums.

Again, awesome stuff though! It'd be a great contribution IMHO.

Version 0, edited 14 years ago by Charlie (next)

comment:4 Changed 14 years ago by Sa'ar Zac Elias

Keywords: Discussion added; sample config configuration removed
Type: New FeatureTask

IMHO this is not needed as all configuration options are shown in our API docs in two ways; as a simple list and as an expanded explanation. But considering the specified benefits I'm leaving the ticket open and calling a discussion.

comment:5 in reply to:  3 Changed 14 years ago by Vytenis Urbonavičius

Replying to comp615:

Sorry should have been more specific. For me, it's to the point where it's hard to navigate. I think it would be more helpful if the following ideas were utilized:

1) Keep similar items together (You did this already)

2) Include plugin settings noting what plugin they relate to: I.E. i didn't see linkShowAdvancedTab.

Currently, I have put everything from this documentation only: http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html

3) Order it in such a way that people are likely to find what they want fast. There's no reason the width setting should be at the bottom while blockedKeystrokes is at the top

Yes, I agree and at some point I came with the same question. However, I have followed the official documentation and the same configuration ordering. Perhaps either both official documentation and sample config file ordering should be changed or neither.

4) Use headings to seperate sections, i.e. General Settings, Style Settings, Plugin Settings, SCAYT settings, ouput settings, etc. Use some of those big fancy ASCII dividers people always use, like below or something that will get noticed:

/************** 
     SECTION 
***************/

Fully agree. As soon as I have some time, I will do this (unless discussion will show that sample configuration is not needed in the project)

5) Consistant style... is it CKEDITOR.config.aaa or just config.aaa? Do you specify what the default behavior/value is? How many examples do we really need for each? For instance, I don't know if you're giving me an example of Protected source notation or if that's the defaults. Defaults can serve as examples, they just need to be notated so people aren't double defining things they don't have to.

Agree. I have made this file for my own projects at first and only then I decided to contribute a little if this appeared useful for others. That is the reason why it lacks consistancy in a few places. I will fix that.

6) Minor formatting, make sure tabs are consistant and all that stuff.

I use Scite editor and under my configuration sometimes it is hard to tell whether I see a tab or 4 spaces. Will be fixed.


I know that's a lot of crap, but what you made is really REALLY helpful to people. I bet they will put it in, but it would have to be very carefully made and organized. (Look at configs like PHPBB or similar and how nicely and succinctly they format everything). Otherwise people will get fed up with searching and keep asking in the forums.

Again, awesome stuff though! It'd be a great contribution IMHO.

Last edited 13 years ago by Wiktor Walc (previous) (diff)

comment:6 Changed 14 years ago by Frederico Caldeira Knabben

Some considerations:

  1. Most of the end developers are js dummies. They could easily see this file as an example of config.js file, and simply reuse it entirely, replacing a 330B thing with a 34KB beast.
  1. The main reason for having the config.js file so clean is to have things loading fast. Point 1 in this list goes against it.
  1. We have all configurations well described, including examples, in our documentation. What about simply adding a link to it in the config.js file?
  1. @DisLike, I know you've spend some good time, providing this nice file. I don't want to go against your suggestion here; I'm just being concrete with my observations, KISS.

comment:7 in reply to:  6 Changed 14 years ago by Vytenis Urbonavičius

Replying to fredck:

  1. Yes, that is sad but true :) However, to solve this I could make two sample config files: one with full configuration available and one with only most common options. The one with most common options could be (perhaps) saved as config.js (main file) so it IMHO it would likely not be replaced by full sample unless it does not contain something very important.

The other one could be called config.full.sample.js (hmmm, rather long one) or config.full.js, config.heavy.js or smth like that to discourage the blind carbon copy :)) IMHO it is likely that once main config file will contain most commonly needed options, heavy one will not be blindly copied.

Or perhaps ONLY the most common options are needed in js file after all? :/

  1. Light sample version would allow to simply uncomment commonly used options and configure CKEditor in a very fast without loading the heavy full configuration sample and without having to study and learn the full configuration. IMHO, most of the time most of configuration is not needed to be changed unless one is integrating CKEditor into some very serious system.
  1. Yes, all configurations are VERY well described. IMHO the link is a must. However, once I have thought of a light config.js file with most commonly configuration available in the file at once, it would save much time for programmers that simply want to get CKEditor running without having to study all the available configuration (it sometimes amazes me how highly this piece of art is configurable).
  1. No, everything is ok :) I am integrating CKEditor into my own CMS, so I wanted to have all the configuration in one place anyway :)

Btw, I am also trying to create some alternative browsing solution for images, because at the moment I simply can't afford CKFinder for my projects :/ (reality of a student starting own business :))) )

comment:8 Changed 14 years ago by Alfonso Martínez de Lizarrondo

Here's another related idea, although far more complex:

Instead of providing a list of config options (that are already available at the docs as stated), create a mega-sample file that helps test and build your own config options.

There are already some samples that show how different options work (enterMode, skins, language) and they recreate a new editor to reflect the current options. This new sample would be for example a split screen, first half an editor, and in the second one a list of options: Enter Mode, Language, coreStyles_..., docType, extraPlugins, ...

Not all the config options might make sense, and some will be quite complex to provide in a nice interface, but this could help a lot of people, specially if besides the editor we provide a textarea with the current options used to configure it that way.

This has another benefit, it can help us to test some feature in the rev.ckeditor.com builds even if none of the samples is configured by default that way, or to show other people how it can be configured (by pasting the proposed configuration, it shouldn't accept it as a parameter to avoid XSS problems)

This sample can provide the options grouped in whatever way we think that it's better, and in the future it might even provide different groupings (by name, by functionality)

Does anyone dares to write it? :-)

comment:9 Changed 14 years ago by Frederico Caldeira Knabben

I think both ideas are to be considered.

Alfonso's idea, the "configurator", is something I've always though about, but never got the opportunity to get developed. It deserves a dedicated ticket.

In this ticket instead, we could consider some changes to the config.js file. Other than the link for the docs, we could add "few" settings in the file. The most commonly used.

Some of the settings we could have: toolbar, language, height, width, uiColor and skin. Thoughs? We should keep it at a minimum really, and those represent the very basic settings that one is mostly supposed to have.

comment:10 Changed 14 years ago by Charlie

All good ideas. If I can throw in my two cents again. Literally half of the questions in the forums deal with with either the contentsCss config option (people still like addCSS), or with case/spelling problems in the config or with something like that.

I think a configurator a la the JW Player Wizard would be awesome with helping some of those people to get going quickly since they often don't find/make it into the CKEditor.config API. In addition, as I noted above, not all config options seem to be documented there...

comment:11 Changed 14 years ago by Alfonso Martínez de Lizarrondo

Filed #6009 for the proposed extended sample.

With regards to the linkDialog config options, check #5915 and #5365. I think that the rest of the config options are properly documented.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy