Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs

Recent posts

Mon 21 Jun 2021

Custom Domino Extensions presentation

Thu 10 Jun 2021

Notes 12 without all the blue

Wed 5 May 2021

Pull public data into Notes on the fly

September, 2021
   01 02 03 04
05 06 07 08 09 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

Search the weblog

Genii Weblog

Integrating EditLive with CoexEdit

Wed 21 Sep 2005, 10:35 AM

by Ben Langhinrichs
Integrating EditLive! for Java 5.0
I started the process of integrating EditLive! for Java 5.0 (from Ephox) with CoexEdit because of a customer requirement.  This is a commercial web based WYSIWYG editor, and it is very powerful and easy to use.  The as-you-type spell checking is great, if you like such things (I don't generally, but I like the availability), the tool bar is easy to use and has all the options you might want.  It is easy to see why this is so popular among commercial web editors.  Here is the entry on EditLive from our complete Web Editors list.



Internet Explorer

Supports Mac OS X, Windows, Linux and Solaris. Supports XML, WebDAV, internationalization, 508 compliance. Version 5.0 was released in August 2005. ActiveX and Java editions also available. (edited per comment)

Challenges to Integration
This editor is different in a number of ways than FCKEditor, Xinha and TinyMCE, the current editors we have integrated, and I wasn't sure how those differences would effect this integration.  EditLive is not open source, so I don't know how easily we will be able to build in support for local images, for example.  It uses a Java applet rather than the browser's editing capability, which does make it very consistent between browsers.  It does mean we won't be able to do the simple textarea replacement technique, and instead will have to use the positioning technique which puts the applet where the textarea would have appeared.  Fortunately, that is pretty easy with the subform approach we use in our integration samples.

Integration Progress So Far
Since the integration databases share a great deal of common structure, I started by copying the FCKEditor with CoexEdit integration database to a new EditLive with CoexEdit integration database.  I am going to document the steps I went through to integrate this for future reference, although I may clean up the steps afterwards if leaving them as they were originally taken would confuse future efforts:

1) Copy the FCKEditor with CoexEdit integration database to a new EditLive with CoexEdit integration database

2) Renamed the FCKEditorSubform to be EditLiveSubform, and the MultiFCKEditorSubform to be MultiEditLiveSubform (used for multiple rich text fields at once)

3) Edited the SampleHeaderSubform to say EditLive for Java 5.0 integrated with Notes/Domino using CoexEdit 1.1

4) Edited the computed subform inside the Example Form to say: @If(@ClientType = "Notes"; "NotesClientSubform"; "EditLiveSubform")

5) Edited the computed subform inside the Multi-Field Example Form to say: @If(@ClientType = "Notes"; "MultiNotesClientSubform"; "MultiEditLiveSubform")

Those were the fairly easy steps that could be done for any integrated database.  A lazier (or smarter) person might even find a way to use the database title in the SampleHeaderSubform and the database path to control the computed subforms, but I do want people to be able to copy the subforms into their own databases and such steps might make it harder.  Anyway, on to the more challenging steps, since I don't really know how EditLive is integrated.

6) Went through several basic editing samples that came with EditLive! for Java, and looked at the source created.

7) In the source, the JavaScript file ../../redistributables/editlivejava/editlivejava.js is used, so on the EditLiveSubform and MultiEditLiveSubform, I edited the HTMLBodyContent field to use /webfolder/redistributables/editlivejava/editlivejava.js 

8) In the source, the style sheet stylesheet.css is used, so on the EditLiveSubform and MultiEditLiveSubform, I edited the HTMLBodyContent field to use /webfolder/stylesheet.css.  Note that you could easily move this into a style sheet resource in the database if you wanted to be able to modify it.  I have not looked at it to see how configurable it is.

9) Since the ReplaceTextArea method used in the new FCKEditor sample didn't look like it would work with a Java applet, I looked in the older FCKEditor integration database that used the Create method.  I copied the BodyWeb field and the Content div that surrounds it and put it in place of the BodyWeb field I had, and also copied the $Return field, as I remembered that as an issue for this sort of integration.

10) I went back to the source from the sample and copied the JavaScript lines that create the applet, modifying them slightly to point to the correct paths and putting them in formula language so that they would work in the computed text on the subform.  The content of the field gets set with the innerHTML technique.

11) I removed extra code from the JS header for the onload logic that isn't needed with this approach

12) I modified the $CoexProperties field to have all the explicit properties necessary, since EditLive isn't a "recognized" editor by CoexEdit yet.

13) I tested, and found that the content was not being changed and realized I had to change the name of the applet invoked to BodyWeb

14) I tested again, fixed the small syntax errors and such issues, tested some more and...

Yippee!  It worked.  Colors, tables, attributes, images (from URLs) all seemed to work fine.  The whole process took about an hour.

Now, this is just a basic integration.  I will now see what special features the HTML generated by EditLive has and do my fancy internal integration with CoexEdit, but that is just icing.  The basic integration worked without any special tweaks to CoexEdit, even though this was a very different kind of editor.  It may sound less than modest, but I am impressed that the CoexEdit model works that robustly.

Copyright 2005 Genii Software Ltd.

What has been said:

370.1. Adrian Sutton
(09/21/2005 04:16 PM)

Hi Ben,

I'm the lead engineer for EditLive! for Java and just wanted to point out a couple of things that might be useful to you. Support for local images should be pretty simple with EditLive! for Java, we can automatically post images using a multipart form upload to any URL you specify when the content is submitted so that's usually pretty simple to integrate.

Also, regarding the Web Editors list, EditLive! for Java actually support Linux as well as Windows, Mac OS and Solaris.

Finally, I thought I'd point out my favorite feature from the 5.0 release - the advanced APIs. This lets you plug your own Java code into our editor and implement some really advanced functionality. You can add your own panels to the insert image and hyperlink dialogs, get access to the actual JTextPane we render the content in (add key listeners, modify content and generally mess around). You can also plug into all the events that drive the editor (all our menu items, toolbar buttons etc, just fire an event that the editor the handles). You can also register your own custom tags with custom defined rendering. There's a lot of power in those APIs to develop really tight integrations with CMS's, repositories etc.

I hope that doesn't sound like a big marketing speel, I'm just excited to see what developers can come up with using those APIs, so if you want to make the integration tighter and easier for users don't hesitate to drop us a line with any questions, we'd be happy to help.


Adrian Sutton.

370.2. Ben Langhinrichs
(09/21/2005 05:16 PM)

Adrian - Thanks for the information. I'll fix up the entry in our Web Editors list.

Since I wrote this, but before I read your note, I started working with the local images. It seems very configurable if I look at the XML configuration file, but while other changes there are reflected, I am having trouble getting it to do what I want with local images (which is basically upload them to a Notes database using a form and upload control). It is a bit technical, having to do with not being able to POST without creating the Notes document first for security reasons, so I will take your advice and check in with your support and see where it takes me. So far, the product looks very good, and the APIs offer all sorts of capability.

Thanks for stopping by and contributing.