Ephox LiveWorks!

Web Content Management for Government Sites with Ephox and IBM

Implementing and managing a web content management system is a difficult task – particularly in a government organization where content has to comply with strict regulations. Using real customer examples, we will discuss how government sites are successfully using IBM Lotus Web Content Management and EditLive! to save time, comply with complicated policies, and provide the widest accessibility.

In addition, the Ephox team will demonstrate a sneak preview of the upcoming EditLive! release – V7 which packs significant new functionality.

Agenda

Introduction (5 min)
IBM Government Industry Toolbox for Websphere Portal (10 min)
How government sites are using EditLive! and IBM Lotus Web Content Management (15 min)
EditLive! interactive demo highlighting helpful features for government including a sneak peak of EditLive 7.0. (20 min)
Q&A (10 min)

About the Speakers

Michael Fromin is currently the director of products at Ephox Corporation. With over 21 years experience in IT, including 10 years in consulting, Michael has worked extensively with Fortune 100 companies and has vast experience in development, infrastructure and help desk management. Mr. Fromin has authored numerous technical articles focused on advanced development techniques for Lotus Domino, Java, and WebSphere Portal.
Krishnan Hariharan has more than 12 years of experience in the field of portals and content management. Krishnan currently works at IBM as the Product/Offering Manager for Lotus Web Content Management and WebSphere Portal Content Accelerator. His main responsibilities include in assessing market trends and leading the strategic direction, positioning and go-to-market strategies for Lotus Web Content Management.

Webinar Recording

Upgrade to EditLive! 7.0.2 changes local settings file location

Tue, 16 Feb 2010 01:42:39 +0000

The EditLive! 7.0.2.42 release changed the location the local settings file for EditLive! is stored. This was in response to problems encountered with roaming profiles in Windows.

How can this affect your local dictionary or username?

Consider the following scenario.

Your production system is running a version of EditLive! prior to 7.0.2. You decide to check out the latest version features, either through the demo at Ephox, or on a development server. When you are next working in your production environment you then add some words to your dictionary.

When the production server is upgraded to 7.0.2 (or greater) you notice your words appear mis-spelt, despite adding them in the past to the dictionary.

So what happened?

The first time EditLive! 7.0.2 is run, it will migrate the contents of the old local settings file to the new location. From then on, it will refer to this new file location.

When you added the words, it was to the old local settings file. As the file contents had been previously migrated when you tested the new version of EditLive, when you upgraded to EditLive! 7.0.2, the new words weren't there.

This also occurs if between the initial load of EditLive! 7.0.2 and subsequent upgrade of the production server the username for Track Changes/Commenting is altered.

Once the upgrade has occurred, changing the username or adding words to the dictionary will continue to function as normal.

Micro-Templating in EditLive!

Mon, 7 Dec 2009 13:44:27 +0000

The new micro-templating feature in EditLive! 7.0 allows non-technical authors to use pre-defined templates to create better looking and more consistent web pages without having to recreate layouts from scratch all the time. This video shows how content authors can use micro-templating and how administrators can configure the available templates.

Enabling Experimental Browser Support

Tue, 1 Sep 2009 18:40:11 +0100

EditLive! supports a huge range of browsers, but when new browsers come out it takes time to test them carefully and ensure we can fully support them and provide the kind of high quality experience EditLive! users have come to expect. While that testing is going on, we often include experimental support for the browser.

By default, experimental browser support is disabled in EditLive! but we do provide a JavaScript call to enable support for browsers that we’re currently in the process of testing. At the time of writing, that is basically just the Google Chrome browser, but other browsers have also gone through this testing process in the past. To enable experimental browser support simply add a call to setExperimentalBrowserSupport(true). Since the setExperimentalBrowserSupport function itself isn’t a documented, public method we recommend checking for its existence first:

if (editlive.setExperimentalBrowserSupport) {
    editlive.setExperimentalBrowserSupport(true);
}

Ephox is unable to offer support for these experimental browsers, however we would encourage you to provide any feedback you have on the LiveWorks! discussion list.

Loading Plugins Based on the User's Role

Tue, 25 Aug 2009 14:03:45 +0100

In some situations, it may be desirable to load different sets of plugins for different types of users. This can be done with any of the ways to load plugins, but it is easiest in most cases when loading the plugins from within the configuration file since most integrations have built-in support for role based configuration files.

To load plugins directly from the configuration file, simple include the same information from the separate plugin XML file directly in the configuration file under the <plugins> element. For example, the filter images plugin uses the XML file:

<?xml version="1.0"?>
<plugin load="lazy">
 <advancedapis jar="filterImages.jar"
  class="com.ephox.editlive.filterimages.FilterImages" />
</plugin>

However, this same information can be included directly in the configuration file instead:

<editlive>
  …
  <plugins>
   <plugin load="lazy">
    <advancedapis jar="path/to/filterImages.jar"
      class="com.ephox.editlive.filterimages.FilterImages" />
   </plugin>
  </plugins>
  …
</editlive>

Note that the URL for the JAR may need to be updated since it will now be relative to the page EditLive! is on rather than relative to the plugin XML file. Using the role-based configuration support in your integration, you can control which users have the plugins loaded, by either including or excluding the definition for the plugin in the configuration file.

Of course, if you are loading the plugin using the addPlugin or addPluginAsText JavaScript functions, you can simply use an if statement in either JavaScript or on the server side to control whether or not the plugins are loaded, however this is more difficult than using the configuration file in most integrations.