2009/12/04

Porting easyUpload to CKEditor

A little while back I was tasked to upgrade the easyUpload plugin to CKEditor 3. Due to a broken leg this job has taken too long, but it's finally starting to see the end, and I think that writting some little posts about the problems/workarounds that I've used might be useful for other people trying to write some plugins/customize CKEditor.

Given the new events in CKEditor at first it looked like it would be possible to directly use the existing dialogs and then apply our changes over them (you can look at the api_dialog.html file to see how it's done). That was my idea after writting the original plugin for FCKeditor, I saw that I used a bunch of existing code so having a way to modify the dialog before it's used would be great. But the reality is that in their current state those dialogs can't be customized without writting lots of code (and ugly code) to change the inner logic. I'm gonna talk about the image dialog to explain some of its problems, of course I expect this to change in due course and a future version of the plugin might be as clean as originally envisioned.

In the image dialog you just can't remove the preview or the scripts will fail. The possibility of removing that part hasn't been considered/tested and so the code uses it without first testing for its existence. This is easy to workaround (just some "if"s that you can check when the plugin is releaded) and I think that it might be fixed in the official version. Anyway, this isn't a high priority item because the preview is quite nice in order to verify how the image will look like, but if someone cares to provide a patch to do it the chances will be higher :-)

Lock size & Reset size buttons: They are a single entity without any identifier. It's possible to hide them only after the dialog has been created (vs using the dialogDefinition event to remove them like it's possible for other elements). I think that the solution that I've included (just splitting each button as a single element and reviewing a little some scripts that expected those buttons to always exist) is also easy to add to the general code. For me the important part here is the removal of the "Lock size" button, for plain users that option must be checked always and they shouldn't have to option to turn it off, removing it from the screen just removes a question from their minds.

"Some of the options have been changed...", yep, if you load the image dialog with an existing image loaded and then you try to dismiss the dialog, this prompt will be shown leaving you wondering what has been changed and doubting about closing the dialog or not. This is due to a delayed initialization to avoid an IE7 rendering bug (it seems that IE has several problems with the sizes of the dialogs under certain conditions), and so that initialization needs to be patched with the fixed function.

Considering the number of elements to remove, the scripts that needs to be dynamically patched (as explained above) and then the new elements to add with their logic I decided that it was easier for me to start with a copy of the image dialog and then apply all the changes there instead of having to find ways to override everything that I needed while trying to retain the original functions to perform their work.

These are some of the problems that I've faced, but not the only ones, although they have different origin so they must be handled in a different post.

 

No comments: