I've just described two critical features of V3 at our docs site:
DOM Abstraction: http://docs.fckeditor.net/FCKeditor_3.x ... bstraction
Memory Leak Free: http://docs.fckeditor.net/FCKeditor_3.x ... emory_Leak
As said, this is critical, so impressions and suggestions are definitely welcome.
Thanks!
Wed, 02/20/2008 - 13:52
#1
Re: DOM Abstraction and Memory Leak Free
Keith
Re: DOM Abstraction and Memory Leak Free
Yup! We'll keep that in mind since the very first line of code to be written.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: DOM Abstraction and Memory Leak Free
Since we'll be abstracting away direct DOM manipulation function calls, Google's leak avoidance approach in GWT may be applicable to us.
DOM Events, Memory Leaks, and You
For the impatient, look at the final section of the article, "GWT's Solution"
We can reuse Google's idea, but implement it in JavaScript instead of in a Java->JavaScript compiler. From what I can understand, Google's idea is roughly, "we allow reference cycles in event handling logic, but we make every such cycle pass through a single critical point for each element. So when we need to clean up that element, we can just break that critical point away and all reference cycles will go away." With a DOM abstraction framework in mind, I believe there are many way to make this idea work, and we don't have to limit ourselves to emulating Google's implementation in JavaScript.
Re: DOM Abstraction and Memory Leak Free
Yes, I have an idea which is similar to the GWT proposal. We would be using the same approach as defined in Expandos Handling at our docs. The biggest difference is that we aim to solve a problem, which is the weak point in GWT. The need of clearing their "__listener" expando.
In GWT, a reference to a JS object is saved in their "__listener" expando. This reference must be then removed to avoid memory leak on page reload.
Our approach instead is using an integer in the expando, which points to an index in an array. That array holds the list of functions listening to the event, which is them fired by our custom dispatcher, which btw abstracts the event object too. The final result is that we have no reference to JS objects in the DOM, avoiding having to destroy the reference on unload.
To summarize... we should be in the right track in this sense.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: DOM Abstraction and Memory Leak Free
Is using a 3rd party framework such as jQuery being considered? (http://www.jquery.com) Since I already use it in many of my projects, the overall result would probably be a reduction in JS weight - since I am already loading jQuery, and FCK's code would be far lighter without implementing its own DOM manipulation. jQuery itself is only 15k with optimal compression.
One criteria to look at might be, what are the most popular Javascript frameworks amongst users of FCK?
I could see clear advantages to working with an existing open source framework; the development effort towards abstraction and browser compatibility is combined across the community, and projects like FCK can focus solely on their features and interface.
Re: DOM Abstraction and Memory Leak Free
You can see previous comment about using other frameworks in viewtopic.php?f=11&t=8437 as well as in other threads.
Re: DOM Abstraction and Memory Leak Free
Wait... the minified version of jQuery is a 52.8 KB file (currently). I'm getting the minified version of it because it uses the same compression mechanism we use for FCKeditor.
From those 50+ KB, I think that 10 KB are useful for FCKeditor or even less. All the rest is useless. So, we would have 40+ KB of stuff we don't need in the FCKeditor code, just to save 10 KB for those who also have jQuery on the page. If we gzip that stuff, we are saving 2 or 3 KB... it doesn't make much sense.
We want instead to isolate some common functions present in several libraries, making it possible to delegate those functions to the libraries. We would be following and approach similar to ExtJS in this sense. In this way we can still save those few bytes, providing some level of integration with V3.
The DOM abstraction in jQuery is quite superficial. It is there just to enforce code chainability. We are proposing a much more complete abstractions, which would satisfy all V3 needs.
I understand your idea though, and be sure we have libraries and frameworks in mind.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn
Re: DOM Abstraction and Memory Leak Free
As long as gzip compression is enabled on the server, the minified version is further reduced to 15kb (http://www.julienlecomte.net/blog/2007/08/13/). Although that's a moot point given your other comments
And, thinking about it more, it'd be a really bad idea to tie the editor to any single framework. So I'll shut my big mouth right about now...