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

How to Deploy a Plug-in within EditLive!

Wed, 1 Sep 2010 18:00:39 +0100

Overview

In talking with our customers, one of the most requested capabilities is the ability to extend or customize the behavior of EditLive!. Many of the most advanced of these scenarios requires the creation of a plug-in. In addition to customizing the editor experience, plug-ins also make the work of extending EditLive! simpler because they provide:

Easier management and deployment of extensions/customizations
More flexibility in deployment – you can choose when to load a plug-in so that users don’t wait for a plug-in to load if they will not use that functionality.

If you are new to EditLive! and plugins we have many plug-ins available via the Liveworks website (http://liveworks.ephox.com) that are available for you to use with the Enterprise Edition of EditLive!.

This article will focus solely on how to best deploy a plug-in within EditLive!. The article assumes you already have a plug-in compiled to a JAR and are ready to deploy it within EditLive!.

Deploy a custom Plug-in

To deploy a custom plug-in you only need to do two things:

Place the plug-in JAR file in a location that is "web accessible" so EditLive can load it at runtime.
Add a <plugin> tag to the configuration file. This tells EditLive that you want to load a plug-in. The plug-in tag will also tell EditLive where to get the JAR file and which class to invoke at startup.

1. "Deploy" the JAR to a web accessible location

There is no requirement on where you must place your plug-in JAR file other than the location must be “web accessible” so EditLive can load the JAR as the editor itself loads.

We would strongly recommend that you do not place your own plug-ins in our standard plug-in folder. We recommend against this, as it is very easy to forget you have placed custom code in that folder. When upgrading EditLive!, we see many customers accidentally overwrite the plug-in folder and accidentally delete their customizations.

What we recommend instead is to put your plug-ins into their own folder and then reference your folder using the <plugin> and <advancedapis> tags.

For this article we will use this technique and have written these instructions assuming that you have created a myplugins folder at the root of your web application.

In your myplugins folder you need to place the compiled JAR file for your plug-in. For example, if you were using our table styling plug-in you would end up with the tablestyles.jar file in the myplugins folder.

2. Add a <plug-in> tag to the configuration file

The second stage of utilizing a plug-in is to tell EditLive to load the plug-in as it starts. The key to this is the <plugin> tag and its child tag <advancedapis>. Using the myplugins folder that you created in step 1 we create the tags to load the JAR as follows:

<plugin>

<advancedapis jar="myplugins/tablestyles.jar" class="com.ephox.editlive.tablestyles.TableStylesPlugin" />

</plugin>

This <plugin> directive must be placed within the <plug-ins> tag that should already exist in your configuration file. EditLive loads a variety of its capabilities via our plug-in mechanism so you will likely see several <plugin> tags in your existing configuration file. After you place your plug-in tag at the end of the list your plug-in will load the next time you start EditLive!.

Confirming your custom Plug-in loaded

Once you have completed the steps detailed above you should restart EditLive! and your plug-in will now be available to you.

Should you want to confirm that this has been successful you can double check this in the debug log. Full details of how to create a debug log can be found at: http://www.ephox.com/support/debug-log.html

If the plug-in has loaded successfully you will see this:

[DEBUG] PluginLoader - -(Thread-104) Plugin loading policy: background

[DEBUG] ClassLoaderFactory - -(Thread-104) creating Class loader for:file:/Users/Shared/offline/web/res/plugins/tablestyles.jar

[DEBUG] PluginClassLoader - -(Thread-104) Loading plugin from file:/Users/Shared/offline/web/res/plugins/tablestyles.jar

If however the plug-in has not loaded successfully you will see an error similar to the following:

[ERROR] InitClassRunnable - -(Thread-163) Failed to load 'com.ephox.editlive.plugins.tablestyles.TableStylesPlugin' from 'tablestyles.jar' using base URL 'file:/Users/Shared/offline/web/res/plugins/tablestyles.xml'. <java.lang.ClassNotFoundException: com.ephox.editlive.plugins.tablestyles.TableStylesPlugin>java.lang.ClassNotFoundException: com.ephox.editlive.plugins.tablestyles.TableStylesPlugin

at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:211)

at java.lang.ClassLoader.loadClass(ClassLoader.java:307)

at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:144)

at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

at com.ephox.editlive.java2.editor.plugins.PluginClassLoader.loadClass(PluginClassLoader.java:45)

at com.ephox.editlive.java2.editor.plugins.InitClassRunnable.run(InitClassRunnable.java:40)

at java.lang.Thread.run(Thread.java:637)

If you see an error and your plug-in has not loaded successfully the first thing to check is that the jar is in a file that is web accessible and secondly that you have entered the correct name and path for the files in the configuration file. Ephox support are available to assist and you can raise a support case via our website if you would like any further details or assistance.

The Plug-in APIs used by these plug-ins are only available to customers of the EditLive! Enterprise Edition.
Ephox Technical Support does not cover LiveWorks! plug-ins.
Please direct any support requests or general enquiries about any LiveWorks! code, integrations or plug-ins to the LiveWorks! mailing list. This code is released as-is with no support and no warranty and is installed at your own risk. We recommend thorough testing of any LiveWorks! project before deploying to any production system.

Benefits of the LWCM EAR Integration

Wed, 1 Sep 2010 01:29:13 +0100

With the release of LWCM 6.1, we redesigned our EditLive! integration for LWCM. Unlike the previous integration, our new integration is deployed as a complete Enterprise Application in Portal (commonly referred to as an EAR deployment).

So what does this mean for you?

WCM Upgrade Safe

One of the biggest problems with the previous integration was that every time you upgraded or patched LWCM, you had to redeploy the EditLive! integration. This could easily result in lost configuration if the all important backup stage was missed.

With the new EAR based integration, it removes these problems as it is not affected by LWCM fix-pack installs.

Clustering

The new EAR deployment approach greatly improves the installation on a clustered environment. Where previously EditLive! needed to be installed in each cluster node you can now use Portal cluster deployment mechanisms to deploy the EAR to all nodes.

Startup Performance

The most important benefit of the new EAR based integration to your end users however is that it significantly improves the startup time of EditLive!.

We've utilised best practice web caching techniques along with Java compression to reduce download times and significantly improve startup times of EditLive!. In fact you can expect a reduction of 70% in startups over the previous integration.

Inline Editing - Loading Content with setContentForEditableSection

Wed, 18 Aug 2010 19:40:47 +0100

When using the Inline Editing feature, content can be loaded into Editlive! in one of two ways: the default behavior (loading the content from an HTML <div>) or via the setContentForEditableSection declaration. Though the <div> method is the easiest, errors often occur when 'runable content' (lash, JavaScript, etc.) is loaded into the editor in this fashion.

HTML with Scripted Elements - Potential Errors

Loading content via the <div> method requires you to load elements onto the page before the editing session begins. Given this, your content is first interpreted by the browser before Editlive is activated. This may not be the behavior desired on your editing page - running scripts meant for display. Worse, this could be a source of confusion for your user as the page loads. Note that in some browsers, the browser may re-render these items each time the user switches between Inline Editing windows.

To guard against this potentially confusing behavior, we suggest that users who expect runable content items to consider the the advanced method.

The Advanced Method - setContentForEditableSection

To allow for the use of runable elements while preventing them from being rendered by the browser, we suggest using the setContentForEditableSection directive when initially loading content on the page. This directive will insert a content string into the editor at page load using JavaScript, bypassing the need to populate the DIV on the page. As the content is not part of the underlying HTML page, the browser will not attempt to parse/run the content.

A call to this function might look like:

editlive_js.setContentForEditableSection('div1', '<p><b>New Content</b></p>');

A full description of using the setContentForEditableSection function can be found here.

How Inline Editing Handles Content

EditLive Inline Editing stores content within a hidden HTML <textarea> element on the page, while at the same time writing out a sanitized version of the content to the specified <div> element for display. Each time a user switches between editable sections content is written out to both of these locations. When a getDocument or getBody request is received, the editor returns the value within the <textarea>.

About Inline Editing

Inline Editing allows EditLive! developers to create multiple editable sections on a page without loading several instances of the editor. A developer can create any number of <div> HTML elements and register those DIV's as editable with Editlive!. A full guide to inline editing can be found in the Developer Guide Using inline Editing Tutorial.

Pasting Into EditLive! - How does filtered HTML make it to the editor from MS Word?

Thu, 15 Jul 2010 22:23:55 +0100

When we copy-paste from a program like Microsoft Word into EditLive, information is placed first on the clipboard and then is inserted into EditLive. Often, we end up with a great deal more on the clipboard than you might expect. A simple line of text might bring with it hundreds of lines worth of style sheet declarations, metadata, and application-specific data, and we don't want this unnecessary markup making it into our HTML! Thankfully EditLive! offers a clean copy-paste from Microsoft Word right out of the box, ensuring that the code that arrives in the editor is clean and standards compliant.

Lets explore how this copy-paste operation works, when are filters applied, and how information makes it from the a Word Document to EditLive.

How does clean copy-paste happen?
The process takes 4 discrete stages, and each is clearly visible within an EditLive debug log. It is suggested that you create a debug log of your own (capturing the steps of a copy-paste action) and then follow along with this guide.

The diagram below represents the 4 stages of the process: pasting, filtering, tidying, and insertion.

First, the user copies inform Microsoft Word and then performs a paste action into EditLive. Looking at the debug log, we see that EditLive has received the data, and a simple copy-paste of one line of text has ballooned to be over 100 lines of code!

The log displays the unfiltered HTML after the following declaration as EditLive interprets the pasted content.

13:48:40:842 [DEBUG] EphoxTransferHandler - -(AWT-EventQueue-3) Import data.13:48:40:843 [DEBUG] EphoxTransferHandler - -(AWT-EventQueue-3) Available data flavors: [...] [MS Word HTML Redacted - It really is that long!]

The unfiltered content appears a second time as it is actually pulled from the clipboard. No filtering has occurred at this point.

13:48:40:890 [DEBUG] EphoxTransferHandler - -(AWT-EventQueue-3) Clipboard data:<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:css="http://macVmlSchemaUri" xmlns="http://www.w3.org/TR/REC-html40"> [...] <p class=MsoNormal>###Content###</p> [...] </html>

EditLive then reads the content and filters out Word-Specific markup. Some styling may be preserved, depending the setup of your configuration file. The resultant HTML (as seen below) is almost right, but still includes un-necessary items. Once completed, any of your own paste filters will be applied at this stage.

13:48:40:893 [DEBUG] EphoxPasteFilter - -(AWT-EventQueue-3) Clean word13:48:40:971 [DEBUG] OfficeImportFunction - -(AWT-EventQueue-3) Content before importing MS-Word lists: <html> [...] <p>###Content###</p> [...] </html>

Finally, EditLive reformats the word-markup-free HTML and removes any containing HTML items that won't be needed. The insert operation is then performed and content appears in the editor window.

13:48:40:986 [DEBUG] InsertHtmlOperation - -(AWT-EventQueue-3) Filtered content: <p>###Content###</p>

We’ve seen that copy pasting from Microsoft Word is a multi-step process, where information moves first to the clipboard, and then into EditLive where it is filtered before actually arriving in your content. Remember that these precautions are taken to avoid unnecessary markup, ensure standards-compliant HTML, and to give you the chance to modify HTML before it arrives in the editor.

But what about other application data that we might want, like track changes?
Unfortunately, EditLive is only able to draw from what an application places onto the clipboard. Things like track changes, page sizes, versioning and owner information just don't make it to the clipboard, and as such are not imported to EditLive.

What if items are making it into the editor that we do not want?
If need to restrict items (tags, images, etc.) from making it from the clipboard into the editor, we encourage you to create your own paste filter to strip out those elements before they can harm your content.

Further Reading
Configure Word Paste Options
Filter Pasted Content