GoogleMaps for CKEditor 3 is almost ready

After lots of work to port all the code to the new architecture both of CKEditor 3 and Google Maps 3, the final version is almost ready.

The missing parts

First and foremost: there are three features available previously that won't be ready in this first version because they aren't available in the Google Maps 3 API and I think that it's better to wait for them to port them instead of doing some partial work that requires time and then it will be thrown away.

These features are:

  • Ability to create and edit lines and areas. Tracked in Issue 2432. In the first versions of the plugin (1.x) I coded some basic editing capabilities for lines showing fake markers, but I think that lot of us are waiting for the port of this feature and hopefully they can port it soon.
  • Option to show/hide the Overview Map at the bottom right corner. Tracked in Issue 1470. Ok, it's not really that important, so it won't be a problem for most of the people.
  • Option to show the Google search widget. Tracked in Issue 1697. It adds a nice touch to some pages, but it isn't really needed for most of the maps.

Of course my biggest concern is the editing of lines and areas. For the moment the editing dialog is able to load existing lines and areas from previous versions and change their properties (width, color, opacity), but not to edit their points. As a partial workaround you can use a KML file, but of course that requires the use of a program to create such file. The good thing about KML files is that they can contain lots of data, but if you want to generate a static image then this won't work (Issue 207)

With regards to the CKEditor side, the integration of the dialogs as elements inside the page and the default CSS provided makes it almost impossible to correctly show the maps inside the dialog: there's a CSS rule that tries to reset several values for all the content inside a CKEditor instance, but the way that it's written breaks the CSS inheritance and only the styles that are applied to one element are shown correctly, it can't inherit things like text-align or cursor from its parents, and any <input> that you try to insert doesn't have the default OS styles (in fact it doesn't have any border or background at all).

So some elements that previously were shown inside the map as info windows (text, lines and areas properties) now have their own CKEditor dialogs because it was a nightmare trying to put the controls in a simplified UI.

But despite moving those controls to their own dialogs, there are still some visual problems with the maps: the drag cursor isn't shown, the pointer cursor is instead a text cursor, all the texts are aligned to the left...

The good things

So those are the bad news, let's see the nice side of the changes

The Maps API v3 doesn't require to sign for a key, so that's one step less to worry about, and it can help a lot if you host your site under different domains.

The overall speed is improved, both GMaps and CKEditor APIs are part of the improvement as they have been redesigned to improve performance. Also, in CKEditor the dialogs aren't any longer a new iframe, so they share the same scope with the page, and once the GMaps API has been loaded it doesn't require another check when the dialog is launched again.

I've been trying to reorganize some parts of the code in order to have a better base planning for future enhancements (I won't make any statement about what or when because they might be a distant future),  but now the code should be easier to make some kind of improvements.

Some little bugs have been squashed, but for the moment and until it's tested in more environments it can include unexpected problems. An example of something that I didn't ever test previously but now I think that it will work (I'll try to test it correctly) is having two editor instances in the same page and editing the maps in one or both of them.

What's left

I've ready almost all the code, now it needs to be tested more thoroughly, tested across some browsers (no, I won't care about old versions), test that it reads correctly data from the previous versions of the plugin.

Also it needs to try to improve the UI in the dialogs, they way that they are done in CKEditor makes it a little harder to get nice results, but I think that I'm finally getting the grip about that and with some tricks it's getting better, although I won't be happy until I really see that it works as expected and not some "it's not too bad".

Then the basic documentation, how to install the plugin and some user docs, I hope to reuse as much as possible from the previous version.

And then it will be finally ready (I guess that in a week from now).

No, it won't be open source. As the v2 of the plugin this one will be available only under a license, people that collaborated for the previous versions will get this one shortly.

With regards to v2, once v3 gets all the missing features I will provide it for free 3 months after the release of the updated v3 version. I don't see any reason to keep that code locked for ever if it has been deprecated by a newer version.