Related link: http://wiki.fckeditor.net/FCKeditor
The problem was straightforward, all I needed was a rich-text editor that would allow me to create XHTML that I could then send back to the client. I already had a textarea, and I just wanted a rich-text replacement. I thought this was going to be simple, but the problem cost me hours. In this entry, I show the process I used to identify a suitable AJAX/Javascript library, read on…
All this for pretty rich text editors, doesn’t seem worth it.
I thought that the process would be as easy as:
- Choose one of two widely used AJAX frameworks
- Drop the right js file in the right directory
- Include it in my master template
- Write some js to render a rich-text editor component
- (maybe) write some onclick code that took care of populating the proper form field
In the end, it was a piece of cake, but getting to the solution took me hours.
The Contenders
I had anticipated that the scriptaculous or openrico people would’ve come up with some sort of rich text component by now, but I couldn’t find a rich-text editor in either project. The app already had a dependency on the prototype library, so I googled rich-text prototype library, but I couldn’t find anything worth looking at. After some research the two candidates I identified were:
Dojo’s site seemed slicker, the documentation appeared to be more professional, and the fact that Dojo is the foundation of jot, made me favor it over FCKeditor. I’ve used FCKeditor before, I knew it worked, but I had never integrated it with a server-side framework. From what I could see, Dojo would provide much more than just a rich-text editor, Dojo is a whole collection of components, code, and widgets. That’s something I’m interested in, so….
Dojo Madness
I proceeded to select Dojo, downloaded the Kitchen Sink distribution, and quickly hit a brick wall. I tried to integrate the dojo.widget.Editor into my system only to have the Firefox Javascript console tell me that the package couldn’t be loaded by Dojo. dojo.require() was failing. I then tailed the access.log, only to see that dojo was trying to load the modules from the wrong path. Here’s the central issue, in this particular application, the request path never maps to a real folder, and it appeared that the dojo library was attempting to find each package from a relative directory. So, while I included the dojo.js by referencing /resources/js/dojo/dojo.js, the library was trying to reference the dojo src tree relative to the request path. So, if my page was /member/edit.do?id=29922, Dojo was trying to load dojo.widget.Editor from /member/edit/src/widget/Editor.js when it should be trying to lod from /resources/js/dojo/src/widget/Editor.js.
After some time screwing around with the dojo.js file, I stumbled on this piece of documentation. I can alter the path prefix that dojo uses to load a particular package with this syntax: setModulePrefix(modulePath, prefix). Great, so I played around with that for an hour, until I looked at the definition of this function in dojo.js. It is defined as setModulePrefix: function(module, prefix), and from what I could gather, the dojo documentation confused the order of the parameters. The documentation says “dojo.setModulePrefix("src/", "dojo");” when it should be “dojo.setModulePrefix("dojo", "src/");“. Note: I’m ready for someone from DOJO to correct me if I’m mistaken, but it appears that the documentation is wrong.
I ended up setting the Module Prefix appropriately for “dojo”, but after another few hours, I couldn’t get the system to work properly because it couldn’t locate other components. I then proceeded to dive into the dojo.js (uncompressed) so I could start the laborious process of printing debug statements with alert(). This is the tedious downside of the new AJAX reality. I tried to load this sucker up in Venkman, but it just wasn’t cooperating. That’s when I started to realize that dojo was trying to load an iframe and a Flash movie called storage.swf for every request. I also couldn’t figure out how to change the path from which it expected to load this flash movie. IMO, this was just too much magic for my taste, all I wanted was a rich-text editor and now I’ve got Flash movies…
I’m positive that other people have spent the time to get dojo working with Java, and I’d encourage them to post solutions to the comment area, but after losing five hours to Dojo, I decided that it was time to punt and go to FCKeditor.
FCKeditor
After my trial by Dojo, FCKeditor was a breath of fresh air. The 3 step installation process is a bit misleading, but getting the widget to render was a piece of cake. I could answer my own questions from the demo code, and I was up and running with working FCKeditor + Struts form in no time.
I ued the code from html sample2 to replace the text area, and then I ussed the code from html sample8 to call GetXHTML() on an instance of the Editor. so, to sumarize, form loads, FCKeditor replaces a textarea, then onclick of the submit button populates that textarea with the XHTML from the FCKeditor.
Step-by-step Integration
-
Download FCKeditor distribution, unpack it somewhere
in your webapp. I unpacked mine in “resources/FCKeditor”. -
Include the fckeditor.js as a script in your page
<c:url var="resDir" value="/resources"/> <script type="text/javascript" src="${resDir}/FCKeditor/fckeditor.js"></script> - Find a struts form that already uses an html:textarea
-
To replace a textarea with an FCKeditor, here’s the script:
<c:url var="fckEditorBase" value="/resources/FCKeditor/"/> <script type="text/javascript"> var oFCKeditor = new FCKeditor( 'notes' ) ; oFCKeditor.BasePath = "${fckEditorBase}" ; oFCKeditor.ToolbarSet = 'Basic' ; oFCKeditor.ReplaceTextarea() ; </script> -
Put the following code in the onclick of your submit button:
var oEditor = FCKeditorAPI.GetInstance('notes'); document.getElementsByName('notes')[0].value = oEditor.GetXHTML(true);
Conclusion
Please if I’m missing something about the Dojo configurtion, leave a comment. I’d prefer to use Dojo as a platform, and if someone has a soution to my absolute/relative path blues, please post it. But, in the meantime, I’m very happy with the simplicity of the FCKeditor-based solution. I can drop the FCKeditor straight into my application without having to modify anything on the server-side.


Nice timing
Thanks so much for writing about this. These sort of things have always been on my "want" list for older apps, but I was going to have to use it for an upcoming app and was always fearful of that often multi-hour, multi-day frustration period of exploring different products. It's great that you condensed it into a short and easy to read introduction!
Clarification
From Tim: "I realized that the article above leaves out some details. Realize that the struts form in question has a textarea: <html:textarea property="notes"/>. If I can grab a free hour from childcare, I'll throw a tarball together with a workign example."
TinyMCE
TinyMCE is another editor which is very configurable, easy to integrate, and has a very active community around it. http://tinymce.moxiecode.com
my observations on Xinha
Great post - I've been struggling with integrating a wysiwyg tool into my web app and have found it to be an immensely frustrating experience. I'm definitely going to check out FCK.
I've been struggling with Xinha over the last week and am about to throw in the towel. I was initially quite impressed with it but I've had to deal with some absolutely ridiculous problems like corrupted html entities, mangled links, an indentation style that drives IE insane and a couple of other things. All of this has ruined the confidence of the customer and myself in the ability of this product to maintain the integrity of the data.
To be fair, it does have a lot of good points, it generates good XHTML and the performance is good. Unfortunately, configuration can be quite a bear. The Xinha support forums are littered with people asking for help and not much help is forthcoming.
Ah, that turned into a rant. Sorry about that. I'm sure Xinha is great for a lot of uses, just not mine.
my observations on Xinha
Interesting, in general I think the frustration with these rich-text components is universal. What's crazy about rich editors is the amount of collective stress we've all spent trying to integrate them into our applications. I think it just points to the fact tht the intersection of browsers, Javascript, and server-side applications is still a blind spot irregargless of Web2.0
...before someone chimes in with the obligatory "In rails everything is easy" message. I'll point to the fact that integrating rails and FCKeditor is a chore (http://www.joshuamcharles.com/rails/fckeditor.html) .
regarding Dojo
I believe you would have found that had you emailed the mailing list with your issue, your time spent on Dojo would have been significantly less. Yes I know, you shouldn't have to, but on a project with documentation in development, it's a great substitute. To give you a hand, I believe these following tips will solve your problems with Dojo in your situation.
1) http://dojo.jot.com/FAQ#Debugging%20on%20Firefox
This link in our FAQ explains how to force Dojo to cooperate with Venkman for debugging purposes.
2) For your problem with dojo.require using the wrong file paths
// Dojo configuration
djConfig = {
baseRelativePath: "/new/path/to/dojo/",
};
This would need to be defined before your tag that loads dojo.js
The method you were attempting to use is designed primarily to allow for people to write their own modules to dojo without intwining their code inside of the main Dojo src folders. For example you could load MochiKit using that method, and instead of dojo.mochi you could call MochiKit code using the "mochi." namespace instead of "dojo."
As far as the manual being wrong it is entirely possible there is a mistake. What link did you find that reference on, I'll gladly verify and correct the problem if it is infact an error.
Well I hope this answers your questions regarding Dojo, and gets you back on your feet with it. If you have any more problems, you can always bring them to the Dojo-interest list (info located here: http://dojotoolkit.org/mailman/listinfo/dojo-interest)
Good luck!
-Karl
regarding Dojo
Agreed, mailing lists would've been a good avenue for questions. But, I think that my experience is representative of the majority of developers who need to intergrate library X with library Y and have a finite amount of attention
Blogging tended to get a good answer relatively quickly. :-) thanks for the response. Despite the initial difficulties, dojo seems to me at least to be a clearer, more comprehesive AJAX alternative. I'm rooting for dojo.
#2 in your response, seems like that note needs to be higher up in the documentation - maybe even a note in the getting started guide. Anyway, what am I saying, I should just submit a patch.
As for the possible type: grep setModulePath on http://manual.dojotoolkit.org/dojo.html
regarding Dojo
Well we still believe that if there is a question, the FAQ should be the first place you look. I think people ingeneral forget the purpose of them these days. They are (and this is my opinion on FAQs) there to serve as a buffer against repeatedly hearing/answering the same questions.
As for better more... intuitive documentation, we have a front-end in the process to aide in building the API's and allowing for cleaner more complete documenation.
Now, on to the unanswered portion of your reply, regarding setModulePrefix, I did a grep on dojo/src, and every function I see of dojo.setModulePrefix() has the exact same design as the API documenation you referenced from the manual. I think where the problem comes in is the names used for the arguments to the function. Which I fixed as of this reply.
In the manual link that you posted, the API calls the 2 variables, "modulePrefix" and "prefix". However, the src code uses "module" and "prefix" respectively the same arguments, just slightly different name on the first one. I can see how this is confusing since the API oringally used "prefix" in both arguments.
How the documentation is written "module" (formerly "modulePrefix" before being corrected to mirror the src code) is used to define the root directory of a developers own javascript module, and "prefix" is used to define the new namespace.
As for your speed response, someone just happened to see this and tell me about it ;) You got lucky hehe. And just to give you some more food for thought. There is actually a wikiBook being worked on by myself and 1 other person that I'm aware of, that is meant to explain the basics of Dojo's features. However, instead of explaining the code behind a certain method (like programatic widget creation), we are focusing on the why you might choose to do it that way verus the parsed markup route and vice versa.
Well, almost midnight and I still have a bit to do before bed. I hope this clears up your problem even further. It honestly looks like a misunderstanding from looking at the same code for too long ;)
Good night,
-Karl
You should check out TinyMCE as well.. http://tinymce.moxiecode.com/
That problem has been hit by others, simply need to know how to create the path structure. If they had any kind of decent documentation, you and others wouldn't have this problem. If you look at their mailing list, people have been pleading with them for a long time for good documentation and tutorials. They resist doing this and can't get it through their head that their project will not get many users without it.
Observation +2.5 months. I'm using FCKEditor at the present, but I'm still not entirely satisfied with the decision. FCKEditor requires a huge number of files, and I'm reconsidering Dojo. Dojo seems a cleaner soution than FCKEditor, and I'm having problems getting a FCKEditor to reload in a replaceable DIV.
Hi,
I had a hard time getting dojo o work, FCK was much easier.
However I would like to use dojo editor because of its sleek look so
any ideas on how to get it to work would be apperciated.
I second iampivot. I would never touch neither one of your candidates since I tried TinyMCE.
I have been looking into DOJO for the last 3 days and it seems really good, but I still havent looking into integrating DOJO with a back end server stuff.
Thanks for this article it was good ..I just happend to read it.
Just my two cents. I integrated dojo 0.4.1 into my springmvc backed application. The document wasn't much of help, but I manage to get the editor working by looking at their example and code, and added:
var djConfig = {
baseScriptUri: "",
isDebug: false
};
before anything. and it works.
However, when I use the dialog widget to collect more adhoc info from the form. Very weird thing happened, and I still haven't got the chance to figure out why yet. Whatever I input in the dialog form element are not been submitted to the httpservletrequest object in my controller. And I am pretty sure this is dojo issue, because when i removed the widget, everything works fine.
Anyway, I am moving to use fck for now, because of the internalization feature. TinyMce is great too.
Thank you for this article. One thing i'm noticing is that "Karl's" post is not appearing (along with several after his) - the one with the explanation of the misunderstanding/fix to your article above.
I just happened to see it when i did a 'view source' on this page because the comment starting with "regarding dojo" seemed to be missing some sentences (that i thought might have been code that didn't render properly).
Thought you'd might want to get that fixed :)
Thank you for point that out. I pasted part of the javascript code in there and that doesn't seem to be rendered properly. But a view source on page will do it.
alert("It is not secure ...");