Rich text inline editing
Lovemore Nalube
lovenalube at gmail.com
Fri Nov 7 20:16:39 UTC 2008
Hi
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)?
Thanks
Lovemore
On Fri, Nov 7, 2008 at 8:11 PM, John Norman <john at caret.cam.ac.uk> 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 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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> <elledge.vcf>_______________________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20081107/8bd75d90/attachment.html>
More information about the fluid-work
mailing list