The EditLive 6.1 release adds a new plugin architecture to make it easier to extend EditLive! Since EditLive! has always been extremely customizable and extendable, plugins don't actually add much more flexibility, what they do provide is:

• Easier management and deployment of extensions, particularly across multiple sites.
• More flexibility in deployment, particularly in terms of reducing the start up time of the applet.

Easier Management and Deployment

Using the plugin architecture, allows developers to bundle up their extensions to EditLive! easily and deploy them to multiple sites really easily, without having to edit multiple files server side. The plugins on LiveWorks! will make use of this ease of deployment by providing plugin definitions for each plugin going forward. To take an example, previously the instructions for deploying the footnotes plugin were:

Installing the footnotes plugin requires two steps, installing the plugin jar and adding the menu item the configuration file.

JavaScript for adding the plugin jar:

elj.addJar("footnotes.jar", "com.ephox.footnotes.Footnotes");

Custom menu item to add to the configuration file:

<customMenuItem name="insFootnote" action="raiseEvent" value="addFootnote"
text="Insert Footnote" shortcut="control shift F" />

With the plugin architecture this will be reduced to just one step:

Register the plugin with the following JavaScript:

       elj.addPlugin("footnotes.xml");

Not only do we avoid having to edit two files, but it also hides the "magical incantations" to define the custom menu item and specify the class to load. The plugin descriptor provides all that information. Soon we'll show you how to set up your server so you that all you have to do is drop the plugin files into a specific directory.

Oh and relative URLs in plugin definition files, resolve relative to the plugin definition itself, so you shouldn't need to adjust the URLs for different sites. You can specify the base URL to use for each plugin if you use addPluginAsText.

More Flexibility In Deployment

When you use the addJar function to load advanced API classes, the jar is downloaded and the class initialized before the editor even begins to load which increases the start up time for the applet. With plugins however, you can specify that the plugin should be loaded in the background so that it doesn't delay the applet start up. The immediate loading behavior of addJar can be provided when required using the "immediate" loading mode, however most plugins should use one of the delayed loading modes:

Background

Background loading is most useful for plugins like the link info plugin, where the functionality isn't required immediately, but also isn't triggered by a menu item being selected. Background loading plugins start downloading when the applet first loads, but in a background thread so the applet can continue starting up. As soon as the jar files are downloaded, the plugin class is initialized and the plugin starts working.

Lazy

Lazy loading is like background loading but, well, lazier. The plugin jars start downloading in a background thread, but the plugin class isn't created until the user specifically activates the plugins custom menu item. Obviously, this requires that the plugin is activated by selecting a custom menu item and that the menu item is defined in the plugin's definition file. The first advantage of this approach is that the plugin doesn't take up any resources at all until it is actually used. However, the main advantage is that because EditLive! knows when the plugin is required, if it's not ready a progress dialog is displayed to let the user know how much longer until the plugin is available and give them a chance to cancel the operation. Since the plugin downloads in the background, it is pretty rare for users to ever have to wait for the plugin to load, but it you have very big plugins1 or users with slow connections, it's nice to know they'll get the best possible experience.

More Than Java

Plugins don't have to use Java code and jars at all, you can specify JavaScript files to load too - it works just like the script was included via a <script> tag in the HTML page. Custom menu items can then raise events out to the JavaScript methods from the script file to trigger custom extensions.

Hints and Tips

There are a few simple things you can do to make best use of the new plugin architecture:

• Make sure your plugins use "background" or "lazy" loading mode if at all possible.
• Use addPluginAsText instead of addPlugin2 to avoid extra HTTP connections back to the server to get the plugin files. Stay tuned for an upcoming post on a really neat way to set this up.

Future Plans

We're keen to keep improving the plugin architecture to maximize its usefulness for developers. We'd love to hear your thoughts on how we can make it better, feel free to leave a comment below or chat to us about it on the LiveWorks! mailing list. Some of the things that are on our radar for possible inclusion:

• More flexible ways to specify when plugins are required, for example ensuring the plugin is loaded before a paste occurs.
• More flexibility in specifying custom user interface elements. Where should custom menu items be added? Do we need ways of specifying toolbar buttons and shortcut menu items?
• Server side management of plugins. Do we need to create server-side management tools for enabling, disabling and configuring plugins? What sort of things would this do?
• Reducing the size of the editor. We'd like to investigate splitting parts of the editor out into plugins to help improve start up time and reduce the download size.
• Seriously, is it spelt plug-in or plugin?

Useful Resources

There's a heap of information on using and creating plugins in our SDK:

• Developer Guide: Creating and Using Plugins
• Tutorials:
  • Simple Plugin Tutorial
  • Creating Plugins Using Advanced APIs
• Reference:
  • addPlugin
  • addPluginAsText
  • Plugin XML syntax
• For a look inside some of the challenges we faced when creating the plug-in architecture take a look at Developing Plugins For Applets

1 - for testing, we had to use the rt.jar from the JRE that contains the entire class library so that there was enough time to see that the progress bar was actually working correctly.↩

2 - and setConfigurationText instead of setConfigurationURL for your config file while you're there↩

This entry is filed under Plug-ins. You can follow any responses to this entry through the Atom feed. You can leave a response, or trackback from your own site.