Rich text inline editing

[lovenalube at gmail.com]

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 msu.edu> 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 utoronto.ca
>> <mailto:colin.clark at utoronto.ca>> 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
>>     http://fluidproject.org
>>
>>
>>
>> --
>> ************************
>> Lovemore Nalube
>> Online Learning Environments Developer
>> Centre for Educational Technology
>> University of Cape Town
>> www.cet.uct.ac.za <http://www.cet.uct.ac.za>
>>
>> /* Work Email: lovemore.nalube at uct.ac.za
>> <mailto:lovemore.nalube at uct.ac.za>
>> /* Cell: 076 186 1244
>> /* GTalk: lovenalube at gmail.com <mailto:lovenalube at gmail.com>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>
>


-- 
************************
Lovemore Nalube
Online Learning Environments Developer
Centre for Educational Technology
University of Cape Town
www.cet.uct.ac.za

/* Work Email: lovemore.nalube at uct.ac.za
/* Cell: 076 186 1244
/* GTalk: lovenalube at gmail.com