Use custom editor if plugin provides one

[dobbs]

No description provided.

[dobbs]

Deployed in glich along with an early draft of slackmatic plugin for experimentation.
https://great-hat.glitch.me/test-slackmatic.html

[WardCunningham]

Thanks for offering a working example for this new work. I fumble through it.

I Choose slackmatic from the factory menu. See this.

I Press save. See this.

I Drop an image. Nothing happens.

I understand that this might be more about enabling a custom editor in factory than about this custom editor. But we should be clear what we would expect of a custom editor and that might be a way to escape from the editor, especially if it has a sequence.

[dobbs]

The updated PR and plugin are now published at glitch to see plugin get pre-loaded
https://great-hat.glitch.me/test-slackmatic.html

[WardCunningham]

I may have pontificated in the wrong field to make my thoughts part of our historical record. The curious can consult #247 (comment).

[paul90]

Let's pull that comment into this thread....

I like this solution. It offers a nice compromise between built-in plugins and load-on-first-use plugins, the two choices we have today. The server admin is choosing to selectively build-in a capability for all users of that farm only.

{
  "name": "Slackmatic",
  "title": "Slackmatic Plugin",
  "category": "other",
  "customEditor": true
}

The example I gave was a plugin's about page talking to itself so the choice of terms was of little consequence. Here a plugin is talking to the Factory about Factory issues where everything is custom. Maybe "custom" is redundant or "true" is missing an opportunity to be more precise. I don't have a specific suggestion. Just recognizing the uniqueness of the channel.

Maybe "custom" is not redundant, it indicates that this parameter is about a custom editor, rather than the standard built-in one. All the core client needs to know is if the plugin supplies a custom editor, so "true" (or "false") is sufficient. As long as there is a standard entry point for the custom editor, that should be quite enough in the core (together with some error handling in case the plugin doesn't really have a custom editor).

[dobbs]

I considered naming this configuration preload in case plugins should have other reasons to be preloaded. But that seemed premature since the only use case at hand is this editor and I would have needed another configuration for the editor anyway. Ward has said a couple times that he had expected to see more innovation in editors. Naming this a customEditor does promote the existing text editor into The Official Editor where at the moment it's really The Only Editor. Perhaps dropping custom from the name is worth it.

[WardCunningham]

You are convincing. I'm in favor with no complaints.

[dobbs]

With this latest commit, I have simplified the config in factory.json as we discussed here. I've also worked a little harder than usual to provide an informative error message for future plugin authors (like my future self) that might configure the factory but mess up the plugin itself

[paul90]

Published as + wiki-client@0.18.1