Do we need a custom editor? Question raised by PR # 12

[dobbs]

We have several requests from the federated wiki community to enable authors to convert algorithmic diagrams into static diagrams. I have implemented the workflow @joshuabenuck suggested (see #12) in last weekend's conversation. That release is deployed to http://wiki.dbbs.co and interested readers can experiment with the interaction workflow over there in browser local storage: http://wiki.dbbs.co/more-about-graphviz-plugin.html

It works okay, but introduces more quirks into our interface and interactions.

After a few days of reflection, I think this is going to call for a custom editor.

Right now there is a chicken-and-egg problem. Like other plugins use wiki's shared textEditor (https://github.com/fedwiki/wiki-client/blob/master/lib/editor.coffee). Here's the sequence:

1. Author writes a new algorithmic diagram and saves it with the editor.
2. The graphviz item is posted to the server as a create event.
3. After <graphviz-viewer> has rendered the SVG image dot and svg properties are added to the item object that's associated with the DOM item (by way of jQuery's data() interface)
4. The author must know to edit the item again for those dot and svg properties to be saved on the server, and must know to add some extra white space so the change is recognized by the editor.

This workflow works okay for the specific case of converting existing algorithmic diagrams. For example, Marc Pierson wants to save the lineup diagram. In this case, the diagram is already created. The edit which removes the algorithm and preserves the static DOT, will be only one edit for Marc or his collaborators.

But for authors interested in harvesting the DOT or the SVG on the server side, there is an imposition requiring them to know this quirk of a second edit.

One solution that comes to mind is to add a callback to the wiki editor that allows the plugin a moment to modify the item before it is POSTed to the server.

Another solution would be for this plugin to implement a custom editor which knows to compute the DOT and render the SVG before saving to the server. We might prefer this rather than inviting that complexity into the common editor.