Rich text inline editing

Michael S Elledge elledge at msu.edu
Fri Nov 7 12:55:13 UTC 2008


Hi Lovemore--

I can answer question 3 in part. Many moons ago there was a decision to 
use FCKEditor because of its broad adoption. Since then replacing it, or 
at least providing TinyMCE as an alternative, has been a high priority, 
but no one within Sakai has had the bandwidth to take it on. At one 
point it was hoped that an accessible version of FCKEditor could be 
developed which would resolve the issue, but I'm not sure where that 
stands at present.

It would be great if you could explore making it available as a plug-in...

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/10a0a11f/attachment.vcf>


More information about the fluid-work mailing list