Rich text inline editing

Lovemore Nalube lovenalube at
Fri Nov 7 20:16:39 UTC 2008


How are you John?

I've seen the Sakai 3.X sandbox instance - FWIW  :)  the guys here at UCT
loved it's layout so much! With regards to which editor is used, I would
think there should be a standardization of which one is used across all of
Sakai instances. Should it get priority before more releases/versions are
made? It isn't good to have people working on Sakai but plugging-in
commercial apps like Sferyx.

Any thoughts on my other questions (just to keep this conversation on key)?



On Fri, Nov 7, 2008 at 8:11 PM, John Norman <john at> wrote:

> FWIW we at Cambridge are looking to build our content authoring solution(s)
> on top of TinyMCE for Fluid compatibility and accessibility. We have Fluid
> inline edit in use for profile pages.
> Exactly how that work will translate into Sakai 2.X features and Sakai 3.X
> features, but I should not assume that Sakai is FCKEditor for ever - indeed
> I believe Etudes consortium uses Spheryx as its editor throughout Sakai.
> John
> On 7 Nov 2008, at 15:09, Michael S Elledge wrote:
>  That's good!  :-)
>> lovenalube at wrote:
>>> 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.
>>> Lovemore
>>> 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
>>>  <elledge.vcf>_______________________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list