Ephox LiveWorks!

Setting The Default Font In EditLive!

Adrian Sutton — Tue, 22 Jul 2008 16:00:24 +0000

One of the questions that we commonly get asked is how to set the default font in EditLive! The answer is actually quite simple, just specify it in your stylesheet. If you already have a stylesheet that you’re using with EditLive! simply add the CSS rule:

body {
  font-family: “Arial”;
}

This will set the default font to “Arial”. You can set the font name to any font you like, but remember that the font may not be available on all the computer that view you pages and if it’s not, it will fall back to the browser’s default font which is usually Times New Roman.

If you aren’t currently using a stylesheet, you can insert it in to the EditLive! configuration file instead. Your configuration file will have a structure like:

<EditLive>
    …
    <document>
        <html>
            <head>
            </head>
            <body>
            </body>
        </html>
    </document>
    …
</EditLive>

You simply need to add a style tag inside the “head” element, like below:

<EditLive>
    …
    <document>
        <html>
            <head>
                <style type=”text/css”>
                    body {
                        font-family: “Arial”;
                    }
                </style>
            </head>
            <body>
            </body>
        </html>
    </document>
    …
</EditLive>

Note that when you specify the style element in the configuration file, it will replace any style tags that already exist in your documents.

The reason EditLive! uses CSS for this is so that it matches the look of your site. Like EditLive!, browsers default to Times New Roman if you don’t specify a font so if you just change the default that EditLive! uses, it would still use Times New Roman in your browser. By specifying the font with CSS instead, it changes in both EditLive! and your browser. Of course, if you specify the style tag in the configuration file, and then only retrieve the body content you’ll need to add the CSS to your site template as well, but if you retrieve the entire document the style tag will be included.

The other advantage of using CSS is that this isn’t limited to just changing the default font. You can change the size, color and a whole range of other settings in the same way, just by including them in your CSS.

Permanently Accepting EditLive’s Certificate

Adrian Sutton — Tue, 15 Jul 2008 15:00:54 +0000

When users first run EditLive! they are asked if they trust EditLive! This is an important security measure to prevent malicious applications from running on your computer but it can be annoying for users to be asked to trust EditLive! repeatedly. Fortunately, it's simple, and for the majority of users the default, to permanently trust EditLive! so the security dialog never comes up again.

For Java 1.4 on Windows, Linux and Solaris, the dialog will look like:

The user can simply click "Always" and the dialog will not be shown again.

For Java 1.5 and 1.6 on Windows, Linux and Solaris the dialog will look like:

The user simply checks the "Always trust content from this publisher" if it's not already checked and then clicks "Run".

Mac OS X makes it a little more difficult. Initially the dialog looks roughly like (this one is actually from our Equation Editor integration):

To permanently trust EditLive! the user must first click "Show Certificate" and the dialog will expand to look like:

Then check the "Always trust" checkbox and then click the "Trust" button.

Using “Pop Out” Mode To Improve The User Experience

Suneth Mendis — Tue, 08 Jul 2008 17:00:12 +0000

Popout window mode is one of the hidden gems of EditLive!. Once the button is pressed, EditLive! pops out from your browser and behaves like a native window which you can move and resize to your hearts content. This means you really don't need to strain your eyes to edit great looking content in EditLive!. Recently I discovered that many users tend to ignore or simply didn't know about this wonderful feature built into the editor. Enabling window mode is really easy. All you have to do is include the appropriate toolbar or menubar item on your configuration file.

Menubar

<menuItem name="Popout"/>

Toolbar

<toolbarButton name="popout"/>

Once the button is included in the configuration file, you will see the pop out icon appear in your toolbar or the menubar or both.

JavaScript

Alternatively, if you like to do this via a javascript button, rather than from the toolbar or the menubar you can utilize EditLive! advance API goodness to get the job done. Process involve 3 easy steps.

Assign a onclick event to your button which call a javascript function

<input type="button" value="Window Mode" onclick="javascript:showWindowMode();"/>

Define a javascript function and call RaiseEvent method on your EditLive! instance

function showWindowMode() {
 EDITLIVE_INSTANCE_NAME.RaiseEvent("openFullWindow");
}

Catch the custom event in your Advance API class in raiseEvent method:

public void raiseEvent(TextEvent e) {
  switch (e.getActionCommand()) {
    case TextEvent.CUSTOM_ACTION:
      if ("openFullWindow".equals(e.getExtraString())) {
        _bean.raiseEvent(new TextEvent(this, TextEvent.WINDOW_MODE, "", 0));
      }
      break;
    }
  }
}

Note that the extra string is the parameter you passed from your javascript function, like "openFullWindow" in this example.

And that’s it really! Now you can enjoy the EditLive! goodness without the applet size constraints. Happy editing!

Getting the URI to a image or file component with the IBM WCM APIs

Robert Dawson — Tue, 01 Jul 2008 15:00:46 +0000

In order to create a link to a file or image component in the WCM repository, there is a 4 step process.

Create a renderer
Set the default context on the renderer to a site area.
Render out a link tag that references the component.
Get the actual desired url using a regex

The code which you can use as a starting point for doing this is included below:

//create a renderer
workspace.createRenderingContext(
    portletRequest, portletResponse, Collections.EMPTY_MAP);
//set the rendered content to a site area
renderingContext.setRenderedContent(siteArea);

//render the component (which will create an a tag)
String linkToComponent = workspace.render(
    renderingContext, fileOrImageComponent);

//get the url for the component (using the below code)
result = getUrl(linkToComponent));

//regular expression that can be used to refer to the rendered link
public static final Pattern IMG_SRC_PATTERN =
        Pattern.compile(
        "<\\s*img\\s[^>]*src\\s*=\\s*\"([^\\\"]*)(\")[^>]*>");

//used a regex to get the url for the component
String getUrl(String url) {
	String result = "";
	Matcher matcher = IMG_SRC_PATTERN.matcher(url);
	boolean found = matcher.find();

	if (found) {
		result = matcher.group(1);
	}
	return result;
}

Certificate Expired Warning Dialog Appears

Adrian Sutton — Tue, 24 Jun 2008 15:00:08 +0000

Symptom

When loading EditLive! for the first time in a browser session, a security warning dialog appears stating that the certificate has expired. Note that this is slightly different to the initial security warning dialog which states that the certificate is valid - that’s normal and users should choose to “Always Accept” the certificate to prevent it reappearing.

Cause

For security reasons, the EditLive! applet is signed with a digital certificate that verifies that the applet is provided by Ephox and that it hasn’t been modified maliciously. This lets users know that it is safe to run the applet. The digital certificates used to do this are issued by a trusted issuer who verifies that Ephox is a legitimate company, however the certificate can only be issued for a specific period of time - usually two years.

The security warning appears once the digital certificate used to sign the editlivejava.jar file has expired.

Solution

The simplest solution is to update to the latest version of EditLive! which will be signed with a valid certificate (we renew the certificate some time before it expires to help avoid this issue). Alternatively, users can simply choose to always accept the certificate again and the warning will not reappear.

Ensuring IWWCM Inline Editing Uses EditLive!

Jack Mason — Tue, 17 Jun 2008 15:00:44 +0000

Symptom

After installing EditLive! for IBM WCM, the default editor is still used when using inline editing. When using the standard WCM interface, EditLive! is correctly used to edit rich text sections.

Cause

The WCM rendering portlet which provides the inline editing has a separate configuration option for which rich text editor to use. In most cases, this setting is correctly changed to use EditLive! when installing but in certain environments the setting may revert to the default editor.

Solution

Log in as the portal administrator.
Go to Portal Administration –> Portlet management –> Portlets.
Search for portlets starting with Web.
Click on the “Configure Portlet” button (displayed as a spanner icon) for the “Web Content Viewer” portlet.
Set the value of the WCM_RICH_TEXT_EDITOR field to “EditLiveJavaEditor.jsp” (without the quotes). If the field is not present, add it.
Save the changes.

EditLive! should now correctly load in both the standard editing form and in the inline editing view.

New Plugin: Paste As Code

Adrian Sutton — Mon, 16 Jun 2008 10:52:56 +0000

Two of our engineers, Andy and Rob have put their heads together and come up with a new plugin to help sites like LiveWorks! that paste code snippets. It provides a “Paste As Code…” menu item that neatly formats the code on the clipboard and marks it up with class names so it’s easy to apply syntax highlighting. A sample stylesheet is included with the plugin.

So in the future you should see much clearer and easier to read code snippets on LiveWorks!

Uninstalling EditLive! for IBM Web Content Management

Adrian Sutton — Tue, 10 Jun 2008 15:00:35 +0000

While we hope you never need or want to, if you ever decide to uninstall EditLive! and go back to using the default editor within IBM’s Web Content Management system (IWWCM), simply follow the steps below. If you’ve decided not to use EditLive! anymore we’d appreciate it if you could drop us a note to let us know why as it will help us to improve our products in the future.

In the IWWCM Authoring interface, click the Configure link.
Expand the Rich Text section. Remove the reference to EditLiveJavaEditor.jsp in the provided text field (so that it is blank). Click OK. The ODC Editor is now the default editor for new rich text fields.
Select your desired Authoring template. Once open, click the Edit button.
Click the Default Content Settings link. Notice that EditLive! will still appear for each registered rich text field in the Authoring template.
For each rich text field element open the properties of the rich text field.
Where the EditLiveJavaEditor.jsp file is referenced, remove the reference to EditLiveJavaEditor.jsp so that the text field is blank.
Save the Authoring template. Each content item which uses this Authoring template will represent Rich Text fields using the IBM editor.
Perform steps 3 to 8 for all the authoring templates where you no longer wish to use EditLive! for IWWCM.

Solving Extremely Slow Load Times

Adrian Sutton — Tue, 03 Jun 2008 15:00:35 +0000

Symptom

Loading EditLive! takes 5 minutes or more. The loading progress indicator may progress but extremely slowly or the browser may appear to have hung.

Cause

The delay in loading is triggered when the editlivejava.jar file is served without a “Last-Modified” HTTP header, preventing the Java plugin from caching the jar. Due to this, every time a new class is initialized the entire jar file is downloaded again. Even on fast networks or local access this causes substantial delays.

In all known cases this has been caused by a web server or proxy misconfiguration. Either the web server is not including a Last-Modified header at all or a proxy server is stripping it out. In particular this issue has been seen with the Vignette Trusted Authentication Service (TAS) and Microsoft ISA Proxy but is possibly with any server or proxy if configured incorrectly.

Note that using the “Pragma: no-cache” header for the EditLive! files does not trigger these extreme load times. The “Pragma: no-cache” header still allows the jar file to be cached, but the plugin checks for updates with every new browser session. If EditLive! hasn’t been updated, the file is not downloaded again.

Solution

The server or proxy configuration must be corrected so that the Last-Modified header is correctly sent. It is not possible to work around the issue within EditLive! or the user’s computer configuration.

Making EditLive! Content Behave More Like Word

Damien Fitzpatrick — Tue, 27 May 2008 17:00:44 +0000

This month I travelled around Australia and met with several long term Ephox clients and talked with them about their experiences with EditLive!, what they’d like to see in the product and what’s coming in EditLive!.

Their feedback was very valuable and it’s safe to say that the trip is likely to be the first of many very client focused trips. In fact, if you’d like to share your own EditLive! experiences, please get in touch with us via the LiveWorks! mailing list, we’d love to hear from you.

One of the things that came up a few times was some inconsistencies between HTML and Word rendering that can cause confusion when users are importing content from Word. There are two simple things you can do to your web site’s CSS to help users out with this.

Firstly, default top and bottom margins. Users experiencing this issue often complain that, when content is pasted from Word into EditLive! there’s “double spacing” between paragraphs. This happens because the top and bottom margins on paragraphs in Word are set to 0, but in HTML it tends to be around 6 pixels or so. The simple solution here is to override the HTML defaults in your CSS by adding something like this:

p{
margin-top:0px;
margin-bottom:0px;
}

It’s worth noting that you could also fix this issue by changing the top and bottom margins in your word processor’s default document template (normal.dot in Word) to match HTML, but it’s much easier to change this in your style sheet because it’s settings are centrally administered.

The second thing that often confuses people more used to creating content on their desktop rather than online is the nature of HTML tables. This is because tables in desktop word processors have a single border, whereas HTML tables, by default actually have two borders. You usually can’t see this because there’s no cell spacing specified. However, if you look at the table below where I’ve set the cell spacing attribute to 2 you can clearly see the borders.

This is because each cell border is made up of two border lines - the border of the cell and the border of either the table or the neighbouring cell.

Fortunately CSS comes to the rescue again. In order to make HTML tables behave just like tables in desktop word processors all you need to do is collapse the table borders. This can be done by adding the following code to your site’s CSS:

table{
border-collapse:collapse;
}

Which will make your table look more like this (note I’ve not changed the cell spacing here, just applied border-collapse):

And that’s it. These two simple CSS changes can make a world of difference for your EditLive! users, especially when they’re importing content from desktop word processors. Just a couple of final things to remember before you start applying this CSS everywhere:

Remember if you’ve got a CMS often the published CSS is different to the authoring CSS that EditLive! uses. Make sure you make the required changes to both sets of styles.
You’ll want to test this CSS in a development/testing environment first to make sure it doesn’t have an unexpected impact on your web site’s layout.
If you’ve already got CSS specified for the “p” tag and/or the “table” tag just add these properties to what you already have.
If you add this CSS to the root element style (i.e. not a class style) like I have above, it should inherit across all the other classes you have in your CSS for tables and paragraphs.

Hopefully you’ll find this very useful and if you’ve got any questions just get in contact with us via the LiveWorks! mailing list.