The main problem about those frameworks/libraries is that it uses the global space to hold many of its functions, like the famous $ function. Running it in an IFRAME would isolate framework on that space, so $('myElement') would run only if "myElement" is inside that IFRAME.
Also, some frameworks extend native objects as one of their features. The isolation would also be a problem for them.
The slickspeed test tool doesn't offer much help on this. It doesn't do any magic. To run it, you need to implement "framework specification files" which tells how to use the selectors for each specific framework.
What I see instead is something that, on its base, is similar to that approach. I see plugins create for specific frameworks that help on integrating then in the editor code with no complications. Of course those things would be needed only for those frameworks that could cause problems.
Hopefully V3 will be done in a way that collisions would be avoided and that problems with other libraries will be rare.
Re: Javascript frameworks within FCKeditor
Also, some frameworks extend native objects as one of their features. The isolation would also be a problem for them.
The slickspeed test tool doesn't offer much help on this. It doesn't do any magic. To run it, you need to implement "framework specification files" which tells how to use the selectors for each specific framework.
What I see instead is something that, on its base, is similar to that approach. I see plugins create for specific frameworks that help on integrating then in the editor code with no complications. Of course those things would be needed only for those frameworks that could cause problems.
Hopefully V3 will be done in a way that collisions would be avoided and that problems with other libraries will be rare.
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
Follow us on: Twitter | Facebook | Google+ | LinkedIn