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 focus? * 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? Thanks, -Noah On Nov 19, 2008, at 8:29 PM, [EMAIL PROTECTED] wrote: > Hi there Noah - an important task for the release will be > http://issues.fluidproject.org/browse/FLUID-1830 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 <[EMAIL PROTECTED]>: > >> 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 - [email protected] >>> To unsubscribe, change settings or access archives, >>> see http://fluidproject.org/mailman/listinfo/fluid-work >>> >>> >> >> _______________________________________________________ >> fluid-work mailing list - [email protected] >> To unsubscribe, change settings or access archives, >> see http://fluidproject.org/mailman/listinfo/fluid-work >> > > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
