Express Edit is designed to be a highly compatible editor that can run even when the user doesn't have Java installed so we load it initially for maximum compatibility. If the user needs the full functionality they can easily click to upgrade to the full editor and their preference will be remembered to give them the best possible editing experience without having to keep clicking upgrade. In most situations this is exactly what you want because the user is then known to have Java installed and be able to run the full editor and it has been downloaded and cached locally so it starts up in around the same time as the JavaScript based editor.

However, for development you often need to revert back to the JavaScript editor for testing. Fortunately, there's a simple way to do that, simply by clearing out the cookie using the Flash Settings Manager. You can either clear all the cookies or just the cookie for the particular site you're working with.

On a technical note, we used the flash cookie to remember the setting to avoid incompatibilities with sites that don't handle extra cookies being returned which would occur if we used JavaScript which we've seen problems with in the past. If flash isn't installed the editor handles it gracefully.

Based on client feedback we are investigating adding an option to force the editor to always load in Express Edit mode but we don't currently have a timeline for it. As always, we'd appreciate any feedback or comments you have on the LiveWorks! mailing list.

One of the major functions of EditLive! that isn't available in Express Edit is track changes. Since the JavaScript based editor has no knowledge about how to work with the track changes information, the change information may become inaccurate or in some cases corrupted1. Fortunately, it is still possible to use track changes in an environment where Express Edit is in use by adding just a little bit of JavaScript logic when loading the editor.

First, there are two important techniques for working with track changes information that we'll use:

• Detecting Track Changes Markup In Documents
• Accepting All Changes With JavaScript
• Accepting All Changes With XSLT

With these tools in hand we can make sure that if track changes information is detected, we always load the full editor:

var hasChangeData = documentContent.indexOf("<trackchanges ") >= 0;
editlive.setExpressEdit(!hasChangeData);

This is enough to ensure that the track changes data is safe, but it will cause the full editor to load even for users that don't have Java installed which is what Express Edit was designed to prevent in the first place. Another option is to warn the user that track changes information has been detected and offer to strip out the change information (using either JavaScript or XSLT). There are many different ways to prompt the user and which is best will depend on your particular appplication, but with the articles above and a bit of knowledge of JavaScript you should be able to create pretty much any interface you want.

1 - the way change information is stored is designed to be as robust as possible so that it doesn't require special handling when processed on the server side, but editing the document can still cause problems.↩

EditLive! provides a rich, full featured and user friendly editing experience, but sometimes you need to roll a system out to users that may not have Java installed and that can sometimes cause deployment headaches. In the past the only option was to give up much of the functionality and ease of use that EditLive! provides and use a JavaScript based editor instead - great for users without Java but limiting and often frustrating for everyone else. So we've come up with a solution that gives you the best of both worlds and we call it Express Edit.

To get as many users up and running as fast as possible, Express Edit adds a JavaScript based editor to EditLive! with a subset of EditLive's functionality yet providing a quick and easy way for users to switch over to the full editor. The best part is that both the JavaScript and the full editor use the same configuration and provide nearly identical interfaces to the user. In fact, taking advantage of Express Edit only requires two minor changes to your existing EditLive! setup.

1. Include the Express Edit JavaScript file. Do this immediately after you include the standard editlivejava.js file, for example:
   <script language="JavaScript" type="text/javascript" src="/editlivejava/editlivejava.js"></script>
<script language="JavaScript" type="text/javascript" src="/editlivejava/expressEdit/expressEdit.js"></script>
2. Instruct the instance of EditLive! to enable Express Edit.
   editlive.setExpressEdit("true");

We think Express Edit is a huge benefit for both users and system administrators. For users, the single configuration for both editors means that the interface is familiar whether they are using the JavaScript editor or the full editor so upgrading to the full editor is painless and just lets them keep working. For administrators and developers, having a single configuration file reduces maintenance costs and dramatically simplifies development and deployment - we've taken care of it all for you.

Since this functionality is so new, you'll need to be using one of the early access builds from version 6.2.7.73 and above. Also, on OS X Java is always installed and available so we always load the full editor. Otherwise, initially the JavaScript editor loads and the user can chose to switch over to the full editor if they desire. Once as user has switched to the full editor, it will load by default to give them the best experience possible by default in future.

Express Edit will be a part of the EditLive! Productivity Pack but feel free to try it out even if your license doesn't include the productivity pack. Over the next few weeks we'll look more in depth at Express Edit and what it can and can't do.