Rich text inline editing

Lovemore Nalube lovenalube at
Fri Nov 7 09:53:24 UTC 2008

Hi All

Thanks to Colin, I have hope that having an accessible Fluid Rich Inline
Editor will be a reality sooner than later.

I ran a test of the patch you provided and it's fantastic. I had a little
trouble with the following;

   1.  The finish() and cancel() functions aren't called properly and hence
   were not working the way they should. Instead, clicking either of them would
   reload the page as though a form had been submitted.
   2. Calling fluid.inlineEdits for multiple textareas will only tranform
   the first textarea and not the rest.
   3. Is there any reason to why TinyMCE was used as opposed to FCKEditor?
   How complex would it be to plugin the latter?

I'm still looking into it, but my thought is that finish() and cancel()
functions are still not visible.

Any pointers will be welcome.

BTW, how can I contribute to the Fluid project :) ?

Kind regards to all

Lovemore Nalube

On Mon, Oct 20, 2008 at 12:11 PM, Colin Clark <colin.clark at>wrote:

> Hey all,
> Recently, I've heard a lot of interest in the prospect of using Fluid's
> Inline Edit component with a rich text editor. So far, it's a feature we've
> done some preliminary design work for, but not something we've looked at in
> depth or implemented yet.
> I wanted to explore how well Inline Edit's current architecture would
> support this use case. In the end, it was really easy to get it working, and
> only involved minor changes to the code. Here are the things I did:
> 1. I wrote a simple new TinyMCE plugin for jQuery. The existing one was
> quite broken.
> 2. I created some HTML markup for my inline rich text editor, consisting of
> a textarea and save/cancel buttons.
> 3. I used my TinyMCE jQuery plugin to unobtrusively turn this textarea into
> a rich text editor.
> 4. I added a public cancel() method to InlineEdit.js, and bound it to my
> Cancel button
> 5. I refactored any code in InlineEdit that assumed we were working with
> plain text and plain old <input> tags. This code now lives in separate
> methods for getting/setting values on both the view and the edit elements.
> 6. I wrote two lines of TinyMCE-specific code to correctly get/set values
> from it.
> That's it. They key is Inline Edit's flexibility with markup, and making
> sure that any assumptions can be overridden for different contexts. To make
> this code cleaner, we may eventually want to break Inline Edit up into
> separate views responsible for handling different types of content and
> editors.
> While I think it's too early to release the whole thing as a
> fully-supported option for Inline Edit, I think the underlying changes to
> the component are useful. I've posted a patch with an example of this code,
> and I'd appreciate it if others in the community could take a look and let
> me know what you think. In particular, check out:
> isEditing()
> cancel()
> setValueOnEditField()
> getValueForEditField()
> setValueOnViewText()
> getValueOnViewText()
> Apologies for the hard-coded paths in the patch. Has anyone else figured
> out how to get Eclipse to create a diff that uses relative paths?
> Thanks,
> Colin
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto

Lovemore Nalube
Online Learning Environments Developer
Centre for Educational Technology
University of Cape Town

/* Work Email: lovemore.nalube at
/* Cell: 076 186 1244
/* GTalk: lovenalube at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list