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.
| Product | Cost | Demo | ND | X | T | A |
|
|
|
|
|
| Remarks |
| | | |
|
|
|
| | | | | |
| 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.