a) It should be possible to lazy-load plugins... A toolbar icon should be included at creation time but the functionality should first be loaded when clicked. It should also be possible to mask the editor (like ExtJS does when loading data) with a "Loading...".
b) Namespaces should be in the reverse Internet domain name convention: <TLD>.<domainname>.<extension>. An example: net.fckeditor.core.EditorPluginX, com.acme.OurPluginA
c) It should be possible to overwrite specific functions of the FCKEditor core (or any plugin for that matter) in an easy way.
d) Dialog popup layouts.... see my [url=/forums/viewtopic.php?f=11&t=8598]previous post[/url].
JohnF wrote:a) It should be possible to lazy-load plugins... A toolbar icon should be included at creation time but the functionality should first be loaded when clicked. It should also be possible to mask the editor (like ExtJS does when loading data) with a "Loading...".
JohnF wrote:b) Namespaces should be in the reverse Internet domain name convention: <TLD>.<domainname>.<extension>. An example: net.fckeditor.core.EditorPluginX, com.acme.OurPluginA
JohnF wrote:c) It should be possible to overwrite specific functions of the FCKEditor core (or any plugin for that matter) in an easy way.
We are definitely on the same track. you have pointed several pretty valuable things that we'll be certainly consider: neat core, extensibility, builder, documentation, central directory... and a lot of fun.
Then regarding the releases, I'm also seriously thinking about it. Much probably it would be a sane decision to concentrate our efforts on the V3, leaving the 2.x branch to critical fixes only. We'll be thinking about it by the end of April.
Thanks for the offer. We are not in the first part of the coding phase of V3. We are doing that in a way that the "builder" can be done later. But it is still too early to really start coding the builder because it should be integrated with services provided by our web site. For example, I would like the builder to retrieve the plugins and skins list from our site, so even third party plugins could be added into the build.
Btw, I'm thinking about making the builder a client program, instead of something to be used on our web site. This is related to the fact that the editor needs several files to run. It is not a single .js file like the libraries found out there. Something interesting could be done with Adobe AIR for it. Well, we'll check it in the appropriate moment.
Then, for the plugins library... this is a service to be provided at our web site. So, it needs to be coded at our side. We are already working on the site btw... we'll have a new design and several new services there.
So, right now, it is still difficult to have some help on the coding of this stuff. But, things that we always welcome are ideas, or even specifications for all that, which could show what people expect having from it.
I posted my suggestion before I take a look into SVN\CKEditor\branches\prototype\, and now I think you're right - it's too early.
About builder - I think it should be server-side tool, integrated with plugins and skins database. Something like this: [ Skins selector ] [ Plugins selector, shows incompatibility with selected theme and plugin known issues ] [ x ] Include compressed scripts and assets [ _ ] Include uncompressed scripts and assets [ _ ] Include full source code [ Download ] [ Preview area ]
So, my ideas for builder are: 1. Download zip file with compressed \ uncompressed scripts \ full source. 2. Preview area for selected skin and plugins Not about builder, but may be usefull ... 1. Add setting into PHP \ ASP.NET \ Java \ JavaScript code to switch between compressed and uncompresed scripts (live \ debug)
In order to avoid problems with a plugin that hasn't been designed to work with older versions (I mean, 2.4 vs 2.5 or 2.6, nor drastic changes like 3.0 although the idea also applies), it's very important to provide an api to get the version number and/or a way for a plugin to specify the minimum version that it has been tested with.
alfonsoml wrote:In order to avoid problems with a plugin that hasn't been designed to work with older versions (I mean, 2.4 vs 2.5 or 2.6, nor drastic changes like 3.0 although the idea also applies), it's very important to provide an api to get the version number and/or a way for a plugin to specify the minimum version that it has been tested with.
What about leaving it just to be displayed in the plugins repository? I'm afraid people will not be testing plugins in older versions, and others would not benefit from it if we would enforce it in some way in the editor code.
But there must be a way to know from a plugin which version of the editor it is running.
Sometimes it's possible to check for a new function or something like that to guess it, and then add the proper workaround in the code (or skip it) for a bug in some function, or a difference in the way that some parameter (like it did happen with the on* events protection) is handled between versions. But that method isn't nice, the code must check for a non-related function to know if some other code has been changed.
And with regards to old versions, most of the time, a plugin for version x doesn't work out of the box with version x-1 as soon as there is any api change in any part of the code involved, it might need an extra call or add the protection that was added in x to fix some bug. When someone wants to use a plugin in a nontested version, he should be aware of that fact, and make some specific move (like editing the plugin to remove the version check) in order to prove that he is at least able to edit js files and deal with some problems due to the use of an old version.
Re: Thoughts about Plugins
a) It should be possible to lazy-load plugins... A toolbar icon should be included at creation time but the functionality should first be loaded when clicked. It should also be possible to mask the editor (like ExtJS does when loading data) with a "Loading...".
b) Namespaces should be in the reverse Internet domain name convention: <TLD>.<domainname>.<extension>. An example: net.fckeditor.core.EditorPluginX, com.acme.OurPluginA
c) It should be possible to overwrite specific functions of the FCKEditor core (or any plugin for that matter) in an easy way.
d) Dialog popup layouts.... see my [url=/forums/viewtopic.php?f=11&t=8598]previous post[/url].
Re: Thoughts about Plugins
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: Thoughts about Plugins
Re: Thoughts about Plugins
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: Thoughts about Plugins
Re: Thoughts about Plugins
We are definitely on the same track. you have pointed several pretty valuable things that we'll be certainly consider: neat core, extensibility, builder, documentation, central directory... and a lot of fun.
Then regarding the releases, I'm also seriously thinking about it. Much probably it would be a sane decision to concentrate our efforts on the V3, leaving the 2.x branch to critical fixes only. We'll be thinking about it by the end of April.
Thanks for your thoughts.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: Thoughts about Plugins
Re: Thoughts about Plugins
thatvetguy
Re: Thoughts about Plugins
Thanks for the offer. We are not in the first part of the coding phase of V3. We are doing that in a way that the "builder" can be done later. But it is still too early to really start coding the builder because it should be integrated with services provided by our web site. For example, I would like the builder to retrieve the plugins and skins list from our site, so even third party plugins could be added into the build.
Btw, I'm thinking about making the builder a client program, instead of something to be used on our web site. This is related to the fact that the editor needs several files to run. It is not a single .js file like the libraries found out there. Something interesting could be done with Adobe AIR for it. Well, we'll check it in the appropriate moment.
Then, for the plugins library... this is a service to be provided at our web site. So, it needs to be coded at our side. We are already working on the site btw... we'll have a new design and several new services there.
So, right now, it is still difficult to have some help on the coding of this stuff. But, things that we always welcome are ideas, or even specifications for all that, which could show what people expect having from it.
Thanks again.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: Thoughts about Plugins
About builder - I think it should be server-side tool, integrated with plugins and skins database.
Something like this:
[ Skins selector ]
[ Plugins selector, shows incompatibility with selected theme and plugin known issues ]
[ x ] Include compressed scripts and assets [ _ ] Include uncompressed scripts and assets [ _ ] Include full source code [ Download ]
[ Preview area ]
So, my ideas for builder are:
1. Download zip file with compressed \ uncompressed scripts \ full source.
2. Preview area for selected skin and plugins
Not about builder, but may be usefull ...
1. Add setting into PHP \ ASP.NET \ Java \ JavaScript code to switch between compressed and uncompresed scripts (live \ debug)
Re: Thoughts about Plugins
Re: Thoughts about Plugins
What about leaving it just to be displayed in the plugins repository? I'm afraid people will not be testing plugins in older versions, and others would not benefit from it if we would enforce it in some way in the editor code.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: Thoughts about Plugins
Sometimes it's possible to check for a new function or something like that to guess it, and then add the proper workaround in the code (or skip it) for a bug in some function, or a difference in the way that some parameter (like it did happen with the on* events protection) is handled between versions.
But that method isn't nice, the code must check for a non-related function to know if some other code has been changed.
And with regards to old versions, most of the time, a plugin for version x doesn't work out of the box with version x-1 as soon as there is any api change in any part of the code involved, it might need an extra call or add the protection that was added in x to fix some bug.
When someone wants to use a plugin in a nontested version, he should be aware of that fact, and make some specific move (like editing the plugin to remove the version check) in order to prove that he is at least able to edit js files and deal with some problems due to the use of an old version.
Re: Thoughts about Plugins
Just to be sure, is the current FCKeditorAPI.Version and FCKeditorAPI.VersionBuild the thing you are looking for?
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: Thoughts about Plugins