Thoughts about Plugins

[fredck]

I've just published the first draft about a generic overview about plugins on V3:
http://docs.fckeditor.net/FCKeditor_3.x ... ugin_Based

Suggestions? Impressions?

[JohnF]

Suggestions:

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].

[fredck]

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...".

Lazy loading is more often related to "load if needed", but I would be depressed to wait for the text to bold when clicking the bold button. I want a responsive interface, so the loading of all UI features "is needed" on start. We could instead avoid loading things that are not available in th UI, and this makes sense, but to avoid having to download dozens of files, a much better result is achieved by properly setting up a "compiled" editor code, with all "needed" features in a single compressed file. Hopefully we'll have better tools to compile it as we want.

Of course, dialogs will be always loaded on demand... or even with a timeout delayed loading.

b) Namespaces should be in the reverse Internet domain name convention: <TLD>.<domainname>.<extension>. An example: net.fckeditor.core.EditorPluginX, com.acme.OurPluginA

Yes... the old Java way... too long and too complex, but well, in the Java world this is needed as naming conflict is much easier to happen.

In our case, naming collisions are rare. They could happen in the Plugin name, so to avoid it we are recommending adding yet another name component, just to be safer. I'm almost sure you will not have much conflicts with your plugin named "JohnF.MyPlugin", instead of "br.com.jonhfoldager.MyPlugin" (if you are Brazilian ). The former would be much easier to remember (nice looking too) than the later. Then, if you change your domain to the international johnf.com, what's going to happen with your plugins? And the dependencies in other plugins? The company/person/product name is not likely to be changed that easily.

Well, we are talking about recommendations. Any kind of name can be used. Even "This is My Plugin" is a valid name.

Your idea is not wrong though. Maybe it is valid to add it as another naming possibility in the recommendation, but a single standard would make things much more uniform.

c) It should be possible to overwrite specific functions of the FCKEditor core (or any plugin for that matter) in an easy way.

This is a pure JavaScript issue. Even today you can overwrite any of the editor functions. It is just a matter of redefining the function. So, your suggestion can be considered already part of it.

[JohnF]

Well... it was our own plugins that I wanted to be lazy-loaded or "loaded on demand". I should have stated that.

Regarding the naming convention... I'm pretty sure that in about 50-100 years from now collisions will occur But anyway.... okay....

No I'm not from Brazil... Denmark

[fredck]

Well... it was our own plugins that I wanted to be lazy-loaded or "loaded on demand". I should have stated that.

Well... you can also offer a plugin that adds a brand new Bold button.

No I'm not from Brazil... Denmark

I imagined that. Just wanted to make the example a bit longer. I'm Brazilian!

[thatvetguy]

My 2 cents...

Make a core as described in the wiki. I'd include the toolbar with buttons and some core functions, eg simple html tag-buttons (strong, em, underline) and lists. Then a context menu and a dialog plugin. Document these all well and make a stable api so that they can be replaced with wrapper plugins to js library's like ext or jquery ui.

Then make a download builder of some sorts that handles dependancy and combines the plugins to only the minimum of files. May be you could use a central CDN for some default download options.

And I would do it ASAP I saw the roadmap for 2.7 and 2.8 but I would concentrate on the plugin mechanism. Table editing and spell checking would become two plugins which could be developed independently. I'd do it like jquery, maintain the core and provide good documentation and a good api. And make it fast and watch for browser compatibility and standards compliance. The good thing with plugins is that if they break, only they break, not the whole editor. And they can evolve independantly and I think it encourages people more to contribute.

Then install the project drupal module so people can list their plugins and people can submit bugs. I wouldn't necessarily provide svn for everyone. They can register themselves a project on google code or similar sites very easily.

My roadmap: I would create the core and the dependancy plugins with an almost stable api, skip 2.7 and 2.8 and release directly as 2.99 alpha or so. Get feedback for the api, convert the other functionality to plugins and release as 2.99 beta. Then work on 3.0 core stuff like XHTML compatibility, etc. and release more beta or rc until the core is ready, the api is stable, the documentation is written and the plugins work (in their current state, not yet improved). Release it as 3.0 and then concentrate on improving the table plugin and spell checker and all the other plugins...

[fredck]

@thatvetguy:

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.

[thatvetguy]

*thumbs up* !

[Kayd]

2 fredck:
Like thatvetguy I think download builder and library of plugins are necessary for CKeditor v3.
I think I can work on both, 5 years in the industry should help me
Also I don't have open source programming experience at all, so I think it is a chance to learn.
PS. I don't want to re-invent the wheel, please let me know if someone already working on it.

[fredck]

@Kayd,

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.