Rich text inline editing

[Michael S Elledge]

That's good!  :-)

lovenalube at gmail.com 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 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
>>>
>>>       
>
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 326 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20081107/f2484de1/attachment.vcf>