In order for the plugin model of V3 to be successful, one big point is a good API, a good set of objects and methods that give proper access to the editor without a need to worry about what's the browser being used or how does the editor internally protects events or anything like that.
Some quick examples:
selections: document the proper way to work with the selection, get its contents, select something...
attributes: some attributes are currently protected, others have to be accessed in a special way depending on the browser (class, label:for, ...) we should have just two methods that take care of reading or setting any attribute on the element. Without having to know if the internal encoding has changed from one version to another.
So I think that it's important to have a well defined API with all the things that might be needed, that should be one of the priorities of this ODE.
Another idea would be to have some routines that aren't included in the core itself, but are designed to make plugins creation easier, kinda like the FUEL library in Firefox , they should be maintained along the core, even if no code in the core uses them at all.
When someone installs the default setup those libraries won't be included, but if you want to develop a plugin that needs some of that code you don't have to write it yourself, it's there ready to use just by adding that "extension plugin" to your setup.
Fri, 02/08/2008 - 22:32
#1
Re: Defining the API
We'll use the docs to better describe each API feature, but just to give you some feedback on your suggestions, and to explicitly list them:
Selection: we definitely need to have better support for it in the API. The current FCKSelection object is not that clear.
DOM Manipulation: it includes attributes, but not only. Actually I have named your idea as "DOM Abstraction" in the docs. Basically, nothing in the code will ever work with real DOM objects (except the DOM abstraction classes). It impacts on the performance of some DOM operations (low impact), but the benefits of it compensate: consistent, full featured and simple API and zero memory leak. More details of it to come.
Extensions/Tools Plugin: a must have. It makes it possible to leave the core clean, giving powerful features for plugin developers. It could also be a set a plugins, instead of a big one (for example Selection Extensions Plugin). In any case, as the core itself will be strongly plugin based, many of the basic features will be available out of the box. It's still unclear what we should have here though, but I'm sure it will get its lines during and mainly after the V3 release.
Documentation: the base for the success of it. Not everybody is able to (or interested on) looking at the code to understand how things work. This time the API should get well documented.
It's nice to have some quick briefs like the above ones right now, so we can consider all those things during the development. So, let's continue throwing our thoughts here in the forums.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn