Rich text inline editing

Noah Botimer botimer at
Tue Nov 25 18:40:25 UTC 2008

Hello, Antranig.

I wouldn't say that I really have requirements.  I would agree that  
strictly unloading on every hide is nasty.  Three specific things I  
have thought of are:

  * When there are a bunch of editors (say, editing a multiple choice  
question in Samigo), do they all load at approximately the same time,  
or do they go sequentially?  And do they block other activity/steal  

  * When navigating at the portal level, how many of these things lie  
around?  Do we run into overall memory issues?  (IE only, I think)

  * Has there been any thought or work on a consolidated toolbar,  
glued to the top of the window/frame?


On Nov 19, 2008, at 8:29 PM, antranig at wrote:

> Hi there Noah - an important task for the release will be
> which will enable  
> lazy
> loading of these edit views. I think, once they have loaded, it  
> will not
> be necessarily desirable to "unload" them since the user may well go
> back almost immediately and try to edit the text again, in the case
> of FCKEditor for example this would feel painful. Right now, as it
> stands, we instantiate all the rich text views on initial page load,
> which is rather more painful.
> We're interested to get your requirements on this. Lazy loading
> currently feels (to me) like a big win, potential for unloading
> less so.
> Cheers,
> A.
> Quoting Noah Botimer <botimer at>:
>> I'm way behind here, but I have a paranoid question (caveat: I have
>> not played with this code)...
>> How does this start/stop rich text editing play with loading times /
>> memory issues?  I'm generally aware of some nasty non-cleanup stuff
>> with these editors (leaving script objects and markup hanging
>> around), especially as iframes navigate around, especially in IE.  Is
>> there anything to worry about here?
>> Thanks,
>> -Noah
>> On Nov 17, 2008, at 11:37 PM, Steven Githens wrote:
>>> Hi Again,
>>> Just had a go playing around with the TinyMCE and FCK versions of  
>>> the
>>> Inline Editor from Fluid Trunk.  The FCK one works great as well
>>> and I'm
>>> excited about it being a good transition for existing Sakai
>>> Deployments
>>> that have customized FCK Plugins and it just generally being used
>>> in all
>>> the tools.
>>> Will these be in Fluid 0.6, or not until 0.7 ?
>>> Thanks,
>>> Steve G
>>> Antranig Basman wrote:
>>>> Steven Githens wrote:
>>>>>> I don't see why you couldn't easily plug FCKEditor in as an
>>>>>> alternative. We can walk you through the process if you're
>>>>>> interested
>>>>> I've been thinking about this too and wanted to vote+=1.  I know
>>>>> TinyMCE
>>>>> is better and being used in all the research for next generation
>>>>> Fluid
>>>>> and Sakai stuff, but I think we'll definately need it to not be
>>>>> super
>>>>> difficult to use this with other Rich Text Editors. ( I think a
>>>>> little
>>>>> difficult would be ok ;)    )
>>>> We will make it easy to work with everything.
>>>>> In addition to Lovemore, I know at least a few other groups  
>>>>> that are
>>>>> doing this same thing manually and would probably love to use the
>>>>> Fluid
>>>>> one as soon as it's ready.  For any medium timeline deliverable  
>>>>> that
>>>>> needs to get dropped into Sakai 2.5 or 2.6 and look like the rest
>>>>> of the
>>>>> system, there is a strong likelyhood it will need to be able to
>>>>> use FCK.
>>>>> Also, I don't how easy it is to swap implementations across the
>>>>> system
>>>>> in Moodle (probably a bit easier than Sakai), but their default is
>>>>> typically HTMLArea, so I imagine they would need to the ability
>>>>> to use
>>>>> that too in order to match the rest of the system.
>>>>> Mega cheers,
>>>>> Steve
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at
>>> To unsubscribe, change settings or access archives,
>>> see
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at
>> To unsubscribe, change settings or access archives,
>> see
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.

More information about the fluid-work mailing list