I'm working on a page for a client, and the [current] design would incorporate 100+ editable divs/elements. I've built this design--and it works--but it takes about 10 seconds for the page to set up, and when clicking on a link to leave the page it lags for a while, and sometimes throws a "Stop script from running" alert. I'm wondering if what I'm attempting(100+ editable inline elements) is simply not possible with the current editor?
As far as technical details, I am using the standard line
contenteditable="true"
and am letting ckeditor.js do its default magic.
Is there any possible way I can get this to work (without lagging?)
Thanks!
Pete

Hi,
Hi,
Something I was thinking about was... what if you only have editors for the elements that are clicked? I have a page with:
You can also set the CSS to change the pointer to the hand. When you move the mouse over the page, you will visually be able to identify which elements are editable by the hover effect of the CSS. Now if you attach an onclick="makeEditable();" attribute to the div and add a function to attach CKE to that div at that time, you can make it launch the editor then and there without having to pre-instantiate the entire page. Better would be if there's a way to destroy the editor when you're done making changes too. I'm not sure if that is reasonably/easily achievable.
Thanks for the reply, Skelly!
Thanks for the reply, Skelly! The same idea came to me last night after the subject had simmered for a while in my head. I'll be working on that today and will report my results back here for others with the same issue. Thanks again for taking the time to leave feedback!
By the way, I just found this
By the way, I just found this in the CKE documentation too for CKEDITOR.editor.destroy()
Using that should allow you to dynamically spawn and kill instances of the inline editor. I'm going to try it as well since the application I am working on may have an unlimited number of editable regions of a given page. You should be able to use the blur event to know when the editor is done editing. Here is how I capture that in my app:My thinking is to put the destroy() call into the blur event and use the onclick() to spawn new instances as needed.
Awesome, good find. I'll put
Awesome, good find. I'll put that to use too.
I already have the lazy creation working for the CKEditor. I've noticed, however, that doing it this way causes the caret to jump. For example, default behavior of the CKEditor is that when you click on an editable text area the caret appears at the location that you've clicked. Using lazy creation, the caret jumps to the beginning of the editable text area. Or sometimes, it shows it "where you clicked" for a moment, then jumps to the beginning as the CKEditor is initialized. This could be an annoyance, especially when working with a long body of text; it would essentially mean you'd have to click once to select the area, then again to move to the point you want to edit.
My desired solution is this:
1. Directly before the CKEDITOR.inline('myDivId') call, save the caret position.
2. Use CKEDITOR.inline('myDivId').
3. Reposition the caret so that it matches the saved caret position.
The hang up is the repositioning of the caret (My question, which you already saw, was posted here: http://ckeditor.com/forums/CKEditor/How-do-you-set-the-cursor-position-in-an-inline-CKEDITOR-instance).
Any thoughts? I've built something that works for the most part, but there are still some kinks. I'll post my solution here if I get something usuable before another solution is found.
UPDATE:
After pulling my hair out for a while I was able to come up with a solution. The trick was in dealing with both NODE elements and TEXT elements, because the setStart() offset refers to different things for each. The solution isn't "IDEAL" so-to-speak, but it's relatively light-weight and most importantly, it works. I plan to write up a blog post soon that will cover this topic. When done I'll post a link to that.
UPDATE #2:
I've sent a pull request to add some events to the inline editor (particularly a floatHidden) event. This will allow us to easily destroy the editor in question when it is hidden.
What did you end up doing for
What did you end up doing for the caret reposition? I found a cross-browser function that emulates IE's rnage.moveToPoint(x,y) (look for the answer with the function getSelectionNodeInfo(x,y) at the bottom of this page) and then in my lazy editor spawn I use it as so:
Yet the caret still returns to the top of the document (offset 0). After fooling around with it a bit, I get the impression that the caret is successfully being relocated and then being moved again by CKE.
One additional thing I am doing with my lazy create/destroy process is I am changing the state of contenteditable="true|false" on my editable div's because if CKE gets in a funny state, the contenteditable=true allows you to go in there and start typing on the div without CKE sitting on top of it. My hope is that doing that does not worsen matters. So far though, eveyrthing appears to be working with the exception of the caret positioning as you pointed out. I was slow to follow this track because I didn't think I was going to implement this model at first, however I am increasingly concerned about not loading down the browser with user-controlled input as you found with dozens of editable spaces in your original issue...
Actually, since posting the
Actually, since posting the last post, I found that my solution was having some bugs--especially in IE8 (but some inconsistencies between the other browsers too). It used an older (and lighter weight) version of the techniques used by Rangy (http://code.google.com/p/rangy/). Rangy may be a fully workable solution--I just haven't had time to try it out yet. I was hesitant at first to add an entire library simply to solve such a simple issue, but if there is no other option then I suppose it is what it is.
Note that I was able to get past the CKE positioning issue by using th following code. I don't know if you've already tried it or not, but if not, give it a try. It may work.
CKEDITOR.on( 'instanceReady', function( event ) { // Reposition caret });With other pressing issues I haven't had time to revisit this topic since I last posted. If you try out Rangy (or another solution) and get something working let me know; I'm definitely interested. I'm becoming more and more convinced that lazy loading the inline CKEDITOR is the way to go.
That worked! Thanks. I had
That worked! Thanks. I had suspected it was just a matter of timing, and that did the trick. I need to do a bunch of cross-browser testing now, but this is looking much better already.
What are you using for your clickX and clickY values?
Skelly,
What are you using for your clickX and clickY values for the line (e.g. how are you grabbing the right values for that).
Also, how have your results been from the cross browser testing?
The second answer on this
The second answer on this page has that function defined. If there is more than one editable region on the page however it only seems to be working on the first one. The second one returns null for elementFromPoint() - I haven't gotten through the troubleshooting on that.
I am going to finish implementation before troubleshooting cross-browser issues. I am using jQuery wherever possible to insulate me from cross-browser issues wherever I can. CKE itself is cross-browser, so I think it should be mostly "ok" once I get through the primary coding.
Regards,
- SK
Err I forgot that I modified
Err I forgot that I modified that function to use jQuery and also added some code to handle multi-line text blocks as the original code did not handle a Y coordinate properly. Here's my modified version of that function: