RTE control needs to be completely decoupled

[neokoenig]

Looks like having the plugin control RTEs directly may cause more issues than it fixes: using window.tinymce (for instance) is probably bad form, as it breaks encapsulation, but also as we don't know the environment the plugin will be deployed in; case: Joomla, autoloading TinyMCE.

However, this means the 'activation' of editable elements need to be done with care, as it may inadvertently trigger RTEs where we don't want them.

[userabuser]

@neokoenig

using window.tinymce (for instance) is probably bad form...

Bad form indeed... like you said, breaks encapsulation. It is too difficult to try and cater for multiple environments from within the core of GM, especially if the list of environments and editors you support grows.

So, what are you thinking regarding this issue?

I have a suggestion, one that is part of an adaptation in a grid manager that I've been working on for an internal project. That, coincidentally, is how I came upon GM in the first place. My Grid project is somewhat different to yours, although Bootstrap based, its not FOSS yet, but we share this problem in common.

I had a need for TinyMCE, CKEditor and a third party editor as each target environments use a different RTE as part of their core distribution and I didn't want to end up with if-else, do-this, or-that kind of logic polluting my core. The goal was to make grid manager agnostic to all RTEs.

There are a number of approaches you can take, some more complex than others, but I'm going to port one of my features for this very purpose into a branch on my GM fork and send up a PR for you to look at and if the shoe fits so be it...

Short gist of it, remove specific RTE dependencies from core plugin, create one consistent API for initializing, attaching and removing RTEs (which GM already has) but using external configs to map the specific RTE API to the core plugin (GM) API.

GM becomes RTE agnostic and then offers you the ability to bundle your own RTEs as defaults to be used as fall-backs for environments that don't natively use an RTE nor want to, but want the RTE capability out-of-the-box when using GM.

Not saying its the best solution, but it does bring back your encapsulation, a little...

I'm still interested in learning more about what you were thinking as a possible solution though and in particular what you mean by:

However, this means the 'activation' of editable elements need to be done with care, as it may inadvertently trigger RTEs where we don't want them.

[neokoenig]

This sounds very interesting - would be great to look at your idea.

Referencing window.anything was a bad move, but hey, it worked-ish :)

The "inadvertently trigger RTEs where we don't want them" bit was quite specific to CKEditor, and actually is probably not applicable now.

Historically, I had all the column elements as contenteditable=true by default, whereas now, contenteditable is applied onclick, and the RTEs use jquery adapters to attach themselves to the editable regions;

The catch was that CKEditor, once included on the page had two issues, 1) that it's autoinline feature meant it would activate itself, and you couldn't then pass in a custom configuration file, and 2) that you potentially had x a milllion instances of ckeditor, which felt bad.

As autoinline defaulted to true in CKeditor, you had to initialise CKEditor with that specific option. Quite annoying.

As you say, the trick is having some form of RTE control within GM, but without necessarily knowing where in the dom it is, and what functions it's therefore exposed... I want to add redactor too, so it would be interesting to see how generic we can make it.