Latest revision as of 19:25, 15 February 2008

(Draft)

First, The Core

V3 will be strongly based on plugins. Before talking about them, let's understand what will compose the core code:

• Manages in page editor instantiations.
• Creates and provides the integration hooks for the main container UI of each editor instance.
• Provides a bridge to access and set the editor data in the page.
• Provides the configuration manager.
• Provides localizability services.
• Provides the event system.
• Handles plugins loading.
• Provides the JavaScript API entry point and some basic API functions.

In few words, without plugins, the core alone will do nothing. It just offers the basic structure needed for the editor to run.

Plugins

A plugin is essentially a JavaScript file that is loaded at the end of the V3 loading process, before its initialization and activation. In this way, the script in the plugin file becomes automatically part of the V3 code base at runtime.

The following are some common use cases for plugins:

• Add UI features, like buttons, context menu options, dialogs, etc.
• Change the behavior of existing UI components.
• Introduce data manipulation features.
• Introduce UI features to be used by other plugins, like toolbars, context menus, panels or a status bar.
• Enrich and enhance the JavaScript API.

Actually, there are no limits on the possibilities we have with plugins. The plugins that make the editing magic come true.

Dependencies

The plugin system will offer a powerful dependency system, making it possible to load specific plugins with easy.

For example, suppose we have a plugin named "LinkColor" that adds a link color button to the link dialog. Suppose we also have a plugin named "ColorButton" that offers a color button for generic purposes, which is used by the former plugin. At that point, it is enough to point the editor to "LinkColor" and "ColorButton" will be loaded automatically, including other possible dependencies defined by the "ColorButton" itself.

Note that the plugin system uses a "registration" system based on names, not paths. To avoid collisions, namespaces should be used to compose the name, leaving namespace-less names reserved to the editor core and to plugins delivered by the core development group. A good and simple naming pattern is: <Company|Product>.<PluginName>. For example: MyCompany.CustomTools or CoolCMS.ArticleLinks.

Plugins Repository

We would like to provide a full featured Plugins Repository at our web site. It should become a central service for our community to easily publish, discuss, develop and search for plugins.

The repository should provide the following features:

• Developers can register any number of plugins.
• Each plugin has its own entry page, with a static naming convention like: http://www.fckeditor.net/plugins/thepluginname.
• SVN repository for the plugin code.
• Possibility of having more than one developer per plugin.
• Admins can add developers and assign other admins. At least one admin must be registered.
• A ticket base to report bugs and features
• A forum to discuss around the plugin.
• A categorized list of plugins.
• Full search in the plugins repository.