jQuery UI, ExtJs integration

[thatvetguy]

Altough I already have written about it here I would like to emphasize the importance regarding the possibility to integrate CKEditor in popular js frameworks that don't have a good html editor (yet).


jQuery doesn't really have a RTE. They have some half-baked, not ready for production solutions (WYMeditor, wysiswyg and others) which are buggy and not very feature rich. There are of course plugins to integrate FCK and tiny but these aren't tightly integrated, especially not with jQuery UI.
ExtJs has only it's own RTE which is limited and people are beginning to write extensions for (only a few). And there are also the integration plugins which IMHO the tinyMCE one currently wins.
YUI has IMHO a decent RTE which is expandable but isn't as feature rich as FCK. I don't know the Dojo editor that good...

The story seems always the same. It is very hard to create a good RTE! Because of lack of time, dedication, browser differences/bugs/annoyances, usability issues, etc... I don't know really. But it is obvious that in almost every js framework project there is a need for a RTE and if there isn't one (which there isn't) people start to try to integrate one of the existing solutions or they try to build their own but that almost never succeeds. How many of these have survived?

WYMeditor is (almost) dead. Nicedit hasn't seen any development since March, there is no writable public repository and the developer is absent from the forum since more than 2 months.

So... Why do I think the integration of CKEditor into JS frameworks like Ext or jQuery or dojo is so important? Because:

• There is no editor that can do it today. There are a few editors out there that can be integrated but there isn't one that can do it right. There's no competition here (yet). Be the first, get the fame.
• Attract professional JS developers. A lot of people are using current RTE editors, from the hobbyist to the professional. JS frameworks attract especially professionals. Getting them involved in the project or gaining them as new users means not only having a broader user base but also more quality bug reports and maybe one or two or twenty future plugin or core developers.
• The users want it too. Users are always complaining about the missing of a RTE. And I'm sure there are more than a few developers out there, that are willing to help on this.
• Framework lead devs want it too. Having a new shiny feature in your library without having to maintain it, great! But there might be licensing issues (jQuery is licensed MIT/BSD)...

I saw that there are scripts for server side integration. Why not create integration scripts for the JS frameworks? Doesn't this make more sense? Because then you're attracting people with skills that this project can use.

Summary: Tight integration with JS frameworks leads to a lot of fame, new users and professional js developers which are able to give back. Which leads to a better project after all I think it's a win-win and now is the best time to lay the groundwork.

(i hope this made sense... it's 2am now...)

[alfonsoml]

Yes, providing integration for javascript frameworks, CMS, blogs and everything that you can think of it's very useful and interesting, but don't forget the most important point: the person that does the integration must be a user of the end system, he must know the way it works, how the preferences should be exposed, what kind of installation steps can be done.

Let's imagine that I say, Ok, I'm gonna integrate it in ExtJS, first I would need to spend a time downloading, testing and reading just how ExtJS works, then I will move to read the docs about how to do the integration and write the code.
That's all?
Not of course, now I have to use it, to test that it works. Provide it to the ExtJS community and listen to their feedback, adjust whatever problem arises, bring new features in the integration per user's request.
And when a new version of FCKeditor is released then I must go back to that integration and verify that everything keeps working, add the new features to the preferences...

Just for one framework

Meanwhile I couldn't have helped in the main core, and I can bet that doing a proper integration with any framework does it takes more than just some hours, add now the support time after the integration is released.

As I said, if you want integration you can't ask just one side. The people that use that framework and are interested in this code are the ones that should move forward in order to have a great system.

Check this page: http://docs.fckeditor.net/FCKeditor_2.x ... tion/Other for example the WordPress integration. He is a user, so he knows what he wants and how it must be done. He keeps it updated.
If someone is hired just to make an integration he will do whatever it's spec'ed and then he will forget about it.

[fredck]

Alfonso pointed out some important things about this task. In few words, there is a lot of work involved in every single integration effort.

But, it doesn't mean that you, thatvetguy, is wrong with your idea. This is btw planned.

For JavaScript frameworks and libraries, we are planning having "adaptors". Each adaptor will inject CKEditor inside the library stuff, making it easy for library users to use it. The first one to be developed is much probably jQuery. After the experience with that, we'll move forward over other libraries.

For application integration instead, there are some efforts at our side for it. As Alfonso said, this work should be done not only by us, but involve the application devs too. We'll be doing that for phpBB, Drupal and MediaWiki.

In all integration efforts, the first huge step is making it work at 100%. At that point, people start using it. It must be at 100%, not 90%, because users must be really satisfied with it. At that point, they will be willing to collaborate with us, and the maintenance of it can move to their hands.

To conclude... we have all this in our head too. Right now, we are focused on the CKEditor release. After that, we'll be able to work on it too.

[thatvetguy]

Yes, providing integration for javascript frameworks, CMS, blogs and everything that you can think of it's very useful and interesting, but don't forget the most important point: the person that does the integration must be a user of the end system, he must know the way it works, how the preferences should be exposed, what kind of installation steps can be done.

That is true for CMS, blogs and other software that embeds and interacts with the editor as a whole. And it is also something that almost every editor out there can do. And I know it depends a lot of end users who are willing to help or do it themselves. But you laid the ground work for it by making it really simple to integrate FCKeditor in webpages.

The integration with a JS framework is on a much deeper level and is something no one has ever done before successfully. These are javascript programmers that need to interact with deep programming concepts of the editor itself and not the editor as a whole. For me it's one level deeper.
I don't know if I can make sense... but someone could take the new core and build a jQuery plugin with it. jQuery itself provides the ajax logic, Ui, implementation strategy, documentation, etc. and the CMS-end user would then integrate it in their system.

For me these are two different kind of programming tasks. You did a great job with CMS integration so I don't have to tell you that. But I'd like you to really not forget the ability to integrate it well with JS frameworks.

Let's imagine that I say, Ok, I'm gonna integrate it in ExtJS, first I would need to spend a time downloading, testing and reading just how ExtJS works, then I will move to read the docs about how to do the integration and write the code.
That's all?
Not of course...

I don't think you should do that. But you may outreach to the other communities for help and ideas? I did that once in the WYMeditor forum but didn't get a response. Don't you think the developers that did the integration plugins for FCKeditor or tiny would be very interested to be involved in this effort? And they may help achieving the goal that at the end it is possible to integrate CKEditor fully in other JS frameworks.

Meanwhile I couldn't have helped in the main core, and I can bet that doing a proper integration with any framework does it takes more than just some hours, add now the support time after the integration is released.

As I said, if you want integration you can't ask just one side. The people that use that framework and are interested in this code are the ones that should move forward in order to have a great system.

Yes you are right. And I don't expect that the CKEditor team would develop all these adapters by themselves. Have you asked in javascript framework mailing lists or forums for help or ideas? I don't think that I should do that as I am not really qualified to speak for you, the developers of this great editor. But if you want I can post in the jQuery mailing list and in the ExtJs forum (the 2 where I am involved) and inform others of the open development effort. Should I?

Check this page: http://docs.fckeditor.net/FCKeditor_2.x ... tion/Other for example the WordPress integration. He is a user, so he knows what he wants and how it must be done. He keeps it updated.
If someone is hired just to make an integration he will do whatever it's spec'ed and then he will forget about it.

But as said before, this is only the end user integration in CMS's. Sorry for the bad analogy, but it feels like Editor1.0.

Editor2.0 would eventually look like this:

CKEditor core + CKEditor UI/Ajax implementation/Context menu -> Wordpress plugin -> Wordpress blog
or
CKEditor core + jQuery.ajax + jQuery UI (colorpicker, themes,...) -> Drupal plugin -> Drupal website
or
CKEditor core + jQuery.ajax + ExtJs UI (windows, tabs, ...) -> Drupal...
or may be
CKEditor core + Flex UI/Remoting/... -> Flex component -> Flex application (-> Air?)

I know I'm in no position to demand something from you guys and I certainly don't want to do that. You can do what you want. But for me this feels like the right step and I wanted to post it so you know it too (if you haven't).

[thatvetguy]

For JavaScript frameworks and libraries, we are planning having "adaptors". Each adaptor will inject CKEditor inside the library stuff, making it easy for library users to use it. The first one to be developed is much probably jQuery. After the experience with that, we'll move forward over other libraries.

It was the intent of this thread to make sure that this is happening. Because I really, really think this would make CKEditor really, really great!

For application integration instead, there are some efforts at our side for it. As Alfonso said, this work should be done not only by us, but involve the application devs too. We'll be doing that for phpBB, Drupal and MediaWiki.

I don't think you need to put a lot of effort in this. When the word spreads that there is this new CKEditor, based on a proven code base, that is easy and tightly to integrate in almost every system, developers will come and build this plugins themselves. There are so much users that want a good working editor in these systems that there will be either pressure for the lead developers to do it themselves or the users will do it if they have the ability to do so. At the moment there excuse is that an integration may be cumbersome and not possible to a certain degree but that isn't the case after 3.0!!

I really don't think this will be an issue at all...

In all integration efforts, the first huge step is making it work at 100%. At that point, people start using it. It must be at 100%, not 90%, because users must be really satisfied with it. At that point, they will be willing to collaborate with us, and the maintenance of it can move to their hands.

As said above, I don't think you have to provide a working integration at all. Just provide a 100%-capable-to-integrate editor (with good, simple api and documentation!!) and people will build it themselves. I think a lot of these open source projects now have the resources to make these plugins themselves. Wordpress eg. has a very customized tinyMCE editor. If I were a drupal core developer I wouldn't care if it took me a month to make a rock solid wrapper around CKEditor's core, maybe even designing a new UI, as long as I knew that it is worth it and this thing is bugfree and maintained and I don't have to think about it after that.

To conclude... we have all this in our head too. Right now, we are focused on the CKEditor release. After that, we'll be able to work on it too.

I read a lot about this concepts in the open development effort documentation wiki. I just wanted to make sure that you are really going in this direction (the specs sometimes read very unspecific). I hope I'm not coming off as rude...

My offer stands. If you need help reaching to other communities for feedback and input, I would gladly help by posting posts like these in their forums or mailinglists.

[fredck]

My offer stands. If you need help reaching to other communities for feedback and input, I would gladly help by posting posts like these in their forums or mailinglists.

Yes, it "will" be great. I'm putting it in the future because, from my experience in other integration efforts, people don't give it much attention to it if they don't have code and examples to look at. So, as soon as we have things running at our side, we'll be able to do a massive integration attempt.

Right now, I think we should be concentrated on the CKEditor coding and on doing the first integration by ourselves. I've elected jQuery for this. In this way we can understand exactly which features we need in the editor to make such integration smooth and powerful.

Your words make a lot of sense thatvetguy. It's cool to have you here with us

[spinal007]

Hi Guys,

I'll be honest, I don't know much about the development of FCKeditor, but isn't this simply an issue of popular libraries such as jQuery providing plugins that can initialise and even manipulate FCKeditor through your existing API?

RE: http://www.fyneworks.com/jquery/FCKEditor/

Cheers,
Diego A.

[fredck]

I'll be honest, I don't know much about the development of FCKeditor, but isn't this simply an issue of popular libraries such as jQuery providing plugins that can initialise and even manipulate FCKeditor through your existing API?

More or less, yes. But, we want it to be clearer, better integrated and mainly "continuously supported". Also, there is a big difference. jQuery support would be part of CKEditor. So, you don't need a plugin for that. It would just work out of the box by adding jQuery and CKEditor to a page. The plugin will be embedded into the editor code (this will be configurable, of course).

[spinal007]

Thanks for the reply. I see where you're going. It definitelly makes sense and I can't wait for it...

[thatvetguy]

Sorry for my (very) unpolite abandoning of this thread. I have nothing to add. Your thinking sounds very good and I have now a lot of hope for the future of CKEditor. It will be a great editor!

Thank you for taking the time to answer my questions! I'm eagerly awaiting the new version to use in my projects!