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 <[EMAIL PROTECTED]> 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! :-) >> >> [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >>>>> <mailto:[EMAIL PROTECTED]>> 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: [EMAIL PROTECTED] >>>>> <mailto:[EMAIL PROTECTED]> >>>>> /* Cell: 076 186 1244 >>>>> /* GTalk: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________________ >>>>> fluid-work mailing list - [email protected] >>>>> To unsubscribe, change settings or access archives, >>>>> see http://fluidproject.org/mailman/listinfo/fluid-work >>>>> >>>>> >>>>> >>> >>> >>> <elledge.vcf>_______________________________________________________ >> fluid-work mailing list - [email protected] >> 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: [EMAIL PROTECTED] /* Cell: 076 186 1244 /* GTalk: [EMAIL PROTECTED]
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
