A change in the recent 6.2 release broke the Drag And Drop plugin, so I've taken the opportunity to update our self-signed LiveWorks! certificate that had expired.  All plugins now have a certificate that is valid until the end of 2008, in addition the following plugins have been updated:

• File Drag And Drop now requires EditLive! 6.2
• Link Info has improved mouse behaviour at the edge of the editor and when the mouse is not directly over a hyperlink

Plugins that specify a loading policy of "background" download in the background while EditLive! is initializing which gives faster start up times and a better user experience. The downside is that the plugin has to handle being loaded at an indeterminate time, possibly during or possibly after the editor has started up. Fortunately, handling this is actually quite straight forward.

As an example, we'll develop a simple framework for a plugin that will automatically convert links the user types in to clickable hyperlinks. We'll develop the initializing code in this article and the link conversion in part two. If you just want to get the functionality straight away, we've made available a ready-to-go plugin.

To get started, we need the standard constructor that takes an instance of ELJBean and stores it for use later. We also add ourselves as an editor event listener which is safe to do anytime and allows us to get notifications when the editor finishes loading.

public class Autolink implements EventListener {
  private ELJBean _bean;
  public Autolink(ELJBean bean) {
    _bean = bean;
    _bean.addEditorEventListener(this);
  }
}

Next, we add the raiseEvent method that looks for the TextEvent.LOADING_COMPLETE event and adds our listener.

public void raiseEvent(TextEvent e) {
  if (e.getActionCommand() == TextEvent.LOADING_COMPLETE) {
    initializePlugin();
  }
}

At this point (assuming we define initializePlugin, which we'll cover in part two), we have a plugin that works perfectly if it's loading policy is set to early. With background loading we also need to handle being loaded after the LOADING_COMPLETE event fires - with the current code, our plugin wouldn't initialize if it missed that event.

Revisiting the constructor, all we have to do is add the highlighted code below to check if the editor has loaded and immediately initialize if it has.

public Autolink(ELJBean bean) {
  _bean = bean;
  _bean.addEditorEventListener(this);
  if (_bean.isInitFinished()) {
    initializePlugin();
  }
}

That's it! Now if the editor is loaded when our plugin loads, the constructor will take care of initialization, otherwise the LOADING_COMPLETE event will trigger it. You can download the complete file and use it as a template for your own plugins.

Astute readers might be tempted to add synchronization to the class to avoid race conditions, however EditLive! actually takes care of it for us. Since plugins are so heavily oriented towards accessing Swing methods, they are always created on the Swing thread and EditLive! only ever calls the raiseEvent function on the swing thread. So our initialization code will only ever be called from the swing thread and we don't have to worry about threading issues.

The downside is that if your plugin needs to do anything complex for initializing, it needs to spawn a new thread to do the initialization off the swing thread or it may interrupt the user's work. Just make sure to use SwingUtilities.invokeLater to jump back onto the swing thread before accessing any Swing or EditLive! methods.

A new feature we've whipped up for the EditLive! 6.2 release is inline editing which allows users to select which portions of rich text they wish to edit in a webpage, rather than loading a new instance of EditLive! for each rich text field.

Implementing inline editing improves your end user experience through the following benefits:

• Faster loading of pages
• Less system resources consumed
• Cleaner, seamless editing interface
• Makes providing seamless inline editing to users extremely simple.

To integrate the EditLive! Inline Editing interface, follow these 3 easy steps:

Step 1) Include both the editlivejava.js and inlineEditing.js script files in your webpage.

<script type="text/javascript" language="JavaScript" src="editlivejava/editlivejava.js"></script>
<script type="text/javascript" language="JavaScript" src="editlivejava/inlineEditing.js"></script>

Step 2) Define each rich text area in your webpage as a DIV html element.

<form>
   …
   <div id="richText1" style="height: 550px;" ><p>div content</p></div>
   …
   <div id="richText2" style="height: 550px;" ><p>div content</p></div>
   …
</form>

Step 3) After the <form> element containing your DIVs, create a script block to define your instance of EditLive!. Add each inline editing section via the addEditableSection API.

…
</form>
<script language="Javascript">
// set the width and height of the editor to expand 100% within the selected DIV.
var editliveInstance = new EditLiveJava("editliveInstance", "100%", "100%");

// set the download directory (the location where the jar file containing the applet lives)
editliveInstance .setDownloadDirectory("editlivejava");

// set the configuration file (start with the sample one).
editliveInstance.setConfigurationFile("editlivejava/sample_eljconfig.xml");

// add the DIV with the id 'richText1'
editliveInstance.addEditableSection("richText1");

// add the DIV with the if 'richText2'
editliveInstance.addEditableSection("richText2");
</script>

This will produce a simple implementation of the inline editing solution for EditLive! When the user clicks in one of the registered
DIVs, an instance of EditLive! will appear in it's place containing the HTML contents of the DIV. When the user clicks into another
registered DIV, the instance of EditLive! will move to the newly selected DIV, leaving behind the updated content in the
previously selected DIV.

You can use any of the normal load time and runtime APIs with EditLive! to configure it as required, simply include them in the script block like normal.

You can also control whether or not EditLive! applies its CSS to help users identify editable DIVs or if you want to simply use your own with the setEditableSectionCSS API.

We've published a new plugin with some simple but highly appreciated functionality - automatically converting URLs the user types in into working hyperlinks. In the next few weeks we'll also be publishing two articles describing how the plugin was created to give you a good start on modifying or extending the plugin to meet your specific needs.

Thanks to the new plugin architecture introduced with EditLive! 6.0, installing the plugin is just one simple line of JavaScript. It could be even easier if you've equipped your system for automatic plugin loading.

One of the aims for LiveWorks! has always been to get the very latest and greatest technologies from Ephox into your hands as soon as possible so you can start evaluating and taking advantage of them. That's why we've now made early access builds of EditLive! available so you can always grab the very latest builds and start taking advantage of them.

These builds are automatically published by our internal build system to ensure they are constantly up to date. These are the same builds that run on all of Ephox's internal systems and are fully supported and have passed our full suite of automated tests. However, unlike our official releases, there is no manual testing done on these builds so we do advise you to exercise caution when deploying these builds into production environments.

So get started with the new builds, try them out and let us know what you think.

One of the really nice features of EditLive! is the highly responsive interface - dialogs open immediately without needing to send extra requests back to the server. That kind of responsiveness comes with a price though - when you first run EditLive! you have to wait for it to download. From then on, the files are all stored on the local machine so you never have to wait again but you still get the responsive interface. The engineers at Ephox have been working hard on making that initial experience better for users and it's something we'll continue to work on, but there are a number of improvements in the 6.2 release that you can take advantage of today.

Firstly, just by upgrading to 6.2 every EditLive! installation will find that the editor starts up faster. We've done a lot of work on start up times and overall performance so that once the files are downloaded everything's ready to go much sooner. We also provide much better feedback to users on startup progress and it just generally looks pretty.

Secondly, with just a minor modification to your site you can make that download time disappear for most users by taking advantage of the new QuickStart function. All you need to do a simple JavaScript function call somewhere like you're login page which will start the download of EditLive! in the background. In most cases by the time the user actually goes to edit their first bit of content the editor will already be downloaded and ready to go. The key advantage to this approach is that it won't distract the user at all. If they don't yet have Java installed it won't start installing it and there are no security dialogs that pop up. It just quietly goes about the download.

To make the experience as seamless as possible for users, we've carefully selected which environments to actually activate QuickStart in. It's all handle behind the scenes for you, but the best experience will be for people using IE on Windows where everything will be downloaded. For FireFox on Windows, we'll warm up the Java runtime but due to bugs in FireFox downloading the resources would sometimes interrupt the user's browsing so we don't actually start the download. On Mac even starting up the JRE might interrupt the user so QuickStart simply doesn't run on Mac. We'll be continuously reviewing what we can do to get more benefits from QuickStart so if you deploy it today you should automatically see the improvements when you upgrade in the future.

To set it up, just add the JavaScript below to the bottom of your login page or even every page on your site - it doesn't matter if the user visits multiple pages with QuickStart, the download will only happen once.

<script src="/product/editliveforjava/editlivejava/editlivejava.js" type="text/javascript"></script>
<script type="text/javascript">ephoxQuickStart("/product/editliveforjava/editlivejava/");</script>

The first script tag includes the EditLive! javascript library which provides the ephoxQuickStart function. The second one actually activates QuickStart. The parameter just specifies the EditLive! download directory where the editor resources are stored. With that one simple change your users will spend less time waiting for things to get started and can just focus on getting their work done which is what EditLive! is really about.

EditLive! does an excellent job of producing standards compliant XHTML, and HTML.  The output can be configured using a large range of configuration options, however from time to time you may want to control the HTML that is generated by EditLive!  There can be many reasons for wanting to do this, from the simple cases of wanting to have control over formatting, to cases where custom HTML tags are used (like in some CMS).

It is possible to step outside the constraints of the configuration file, and take advantage of the Advanced APIs to write a custom source filter to be used with EditLive!.  A source filter makes it possible to change the HTML that works with EditLive!, either when the HTML is coming out of the design view, or when the code is going into the the design view.

The SourceFilter is a simple Java interface, with two methods:

filterIn (filter html going into the design mode of EditLive!)

filterOut (filter html going out of the design mode).

These methods both have a single string parameter (the html text) and return a string (the output html).

The Simple Source Filter java class contains a simple source filter implementation that minimizes the amount of space that list items take in the output.  This is done with a regular expression.

The code in this filter changes:
<li>
    hello
</li>
to:
<li>hello</li>

This example (and others) can be installed and run using the Ephox Plug-in architecture (described in this liveworks article).  As source filters work early in the documents lifecyle they should be loaded using the early loading option.

The source filter plugin.xml would look something like this:

<?xml version="1.0" encoding="US-ASCII" ?>
<plugin load="early">
  <advancedapis
    jar="SimpleSourceFilter.jar"
    class="com.ephox.example.SimpleSourceFilter" />
</plugin>

It assumes that the SimpleSourceFilter class has been compiled and put into the SimpleSourceFilter jar file.