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.

For many sites, it can be useful to have different configuration files based on the actual content being edited. For instance, the image and hyperlink lists may be dynamically generated to include only what's relevant to the current page or change where images are uploaded to etc. The first time people try this they tend to run into the caching that EditLive! performs and find that the config file is never reloaded. The reason EditLive! caches this file so heavy-handedly is that we've found that the slowest part of EditLive! starting up is quite often downloading the configuration file and everything else has to wait for that download to finish.

If you really need to the configuration file to update there are a couple of simple ways to achieve it. The best way is to use setConfigurationText instead of setConfigurationFile which provides the config inline in the web page and removes the need to for another HTTP request altogether. EditLive! won't perform any caching of the config in this case so your changes will appear immediately. We strongly recommend taking this approach even if your configuration file never changes to make the editor load faster.

If however you absolutely have to download a separate URL, or if you just want a quick work around and load time isn't an issue for you, then you can simply append a dummy parameter to the end of the URL which will force EditLive! to download it again each time. The current timestamp is generally a good value to use, for example:

editlive.setConfigurationFile("eljconfig.jsp?cacheBuster=" + new Date().getTime());

Just remember that the extra HTTP request is going to cause a delay in the editor loading, so you'll get a big benefit from using setConfigurationText instead.

See also: setConfigurationText in the EditLive! SDK

We've seen a few customers recently creating custom dictionaries with words that simply won't be checked by our spelling checker; we use a third party spelling component so we don't have much control over this process.  Here are the rules that the component uses to determine which words will be checked for spelling errors, keep these in mind when constructing a custom dictionary.

• A word is an alphanumeric character followed by any sequence of alphanumerics or apostrophes.
• Hyphens are word delimiters, hyphenated words will be checked separately.
• Periods surrounded by alphanumerics are considered part of the word, and trailing periods are considered part of the word if the word contains embedded periods interspersed among no more than two consecutive alphanumerics (e.g., the period at the end of U.S.A. is considered part of the word, but the periods at the end of USA. and ephox.com. are not).
• Apostrophes at the end of a word are considered part of the word if they are preceded by the letter "s".
• An "at sign" (@) is considered part of the word if it is surrounded by alphanumerics and the following word contains embedded periods (i.e., appears to be an e-mail address).
• The string "://" is considered part of the word if it is surrounded by alphanumerics (i.e., appears to be part of a URL).
• A slash (/) is considered part of the word if it is surrounded by alphanumerics and the preceding part contains embedded periods (i.e., appears to be part of a URL).
• Characters &, %, +, =, ?, and _ are considered part of the word if the word contains embedded periods (i.e., appears to be part of a URL).

There are some special cases that we support.  Both can be changed by creating a file called "Spelling.properties" in your dictionary jar file and adding the text as specified below.  If you specify both options, each must be on a separate line.  For an example of this, look at the contents of our French and Italian dictionary jar files.

• Hyphenated words can be checked as a single word with the option SPLIT_HYPHENATED_WORDS_OPT=false.  With this turned off, hyphens surrounded by alphanumerics are considered part of the word.
• Apostrophes can be turned into word delimiters with the option SPLIT_CONTRACTED_WORDS_OPT=true.  This is turned on by default in our French and Italian dictionaries.

Note that both of these options are global, if changed they will apply to the entire editor - not just your custom dictionary.

One of the lesser know, but very useful functions of EditLive! is the ability to customize the spelling dictionaries. This allows you to add domain specific words or specific company titles that your authors regularly use. We've had an article in our documentation for quite some time on how to do this, but with all the options to configure EditLive! it often gets missed.

So, if you're sick of that red squiggly line, take a look at Creating, Modifying and Adding to Dictionaries, one of the hidden gems in our documentation. It's actually quite simple.

I'm pleased to announce that the LiveWorks! Early Access Program has been updated with seed builds of the upcoming EditLive! 6.4 release. We'd greatly appreciate it if you could take some time to try out the new builds and give us any feedback you have, both positive and negative.

While we normally try to maintain a single branch of EditLive!, the features scheduled for 6.4 were considered to have too high a risk of regressions during the development process, so we are now maintaining separate "stable" and "development" branches. The early access page now provides access to both the latest build from both branches.

The 6.4 release is largely focussed on improving our CSS support to make EditLive! more compatible with the latest CSS best practices and generally make it easier to create great looking content within EditLive! While most of the work so far has been "back-end" style changes, but a few improvements have shown through around correctly sizing fonts and support for 'em' sizes. We're also particularly interested in any feedback around floating images as a significant amount of back-end work has been done in this area to enable us to fix some long standing bugs and generally improve our floating support.

A new build is generally made available each day.

Editor’s Note: From time to time while developing with IWWCM, we discover useful gems of knowledge that we think everyone working with IWWCM should know, even if they don’t relate directly to our products. This is one of those nuggets of wisdom that we’d like to share.

IBM Workplace Web Content Management (IWWCM) Version 6 provides a variety of different searching options. These are discussed in the Best practices for using IBM Workplace Web Content Management V6 document, and from a high level are: 

• Workplace Web Content Management API
• WebSphere Portal Search, and 
• Third-party search product

Workplace Web Content Management API

The IWWCM APIs do provide a limited search API. Before investing time in building a search using the APIs, the following points should be considered:

• there is some degree of reinventing the wheel, as the WebSphere Portal Search, and third party search products already provide search.
• the APIs do not provide full content search, instead searches are performed using the Document Ids of meta data (siteAreaIds, categoryIds and keyword ids).

WebSphere Portal Search

Publishing IWWCM Content to the portal search system and integrating this with your WCM system is not immediately obvious, but is explained in the WCM Infocenter.

To make this work you will need to follow steps outlined in the infocenter. Your content will then be regularly crawled by the portal search service, and included in the collections that you have set up. This allows fine grained control on search, including web content in which ever search collections are relevant.

A potential advantage of using this approach is the availability of the content through the Search and Indexing API (SIAPI). This may not work in all portal configurations, and may require troubleshooting to enable.

Third Party Search

A number of third party search options are also available, including IBMs OmniFind, and LuciFind.  These will provide rich search functionality, but require additional purchases, and may have some integration overheads.

Conclusion

There are three main different search options available with IWWCM. The WCM API option is not recommended to be used as it provides limited search options, and requires development of a custom search engine.

The Portal search API will often provide enough search functionality, but it is somewhat limited in the options available, and so a third party search may be required (as noted on this Developer Works forum thread).  While the WCM API provides some search functionality it is not recommended.  The Portal search API is worth considering as a starting point, as it is straight forward to integrate and deploy.  If it does not produce the desired results, a third party search should be used.