Rich text inline editing

lovenalube at lovenalube at
Fri Nov 7 15:07:02 UTC 2008

Hi Mike

Thanks for detailing why TinyMCE is used since FCKEditor is used
almost everywhere in Sakai, I understand the frustration the community
is going through.

To be honest, I understood the point from your first e-mail.


On 11/7/08, Michael S Elledge <elledge at> wrote:
> Hi Everyone--
> I guess I had some early morning dyslexia and read Lovemore's note
> backwards. TinyMCE was used instead of FCKEditor (I assume) because
> University of Toronto has made it accessible. FCKEditor has not, to the
> best of my knowledge, become an accessible tool (which has caused us
> much frustration in Sakai).
> Mike
> Lovemore Nalube wrote:
>> 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
>> <mailto: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
>> <mailto:lovemore.nalube at>
>> /* Cell: 076 186 1244
>> /* GTalk: lovenalube at <mailto:lovenalube at>
>> ------------------------------------------------------------------------
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at
>> To unsubscribe, change settings or access archives,
>> see

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

More information about the fluid-work mailing list