custom editors extend noflo-ui

[forresto]

Now components can be edited with the code or subgraph editor.

I'd like to be able to define more editors for different kinds of components.

• Timeline #151
• Vectors in automata/noflo-canvas#1 could be dragged above the actual output canvas view.
• The three.js editor could be another view, which would sync a scene JSON with the graph.
• Spreadsheet editor for tabular data.

The point is to match the metaphor, and extend noflo-ui as needed.

The editors could be custom-elements, and define where they should be displayed:

• card
• bottom half (timeline, code)
• full screen (threejs, subgraph)

The question: how to define, package, (lazy-)load the elements?

[forresto]

Working on noflo/noflo-canvas#3 I've been imagining plugging a timeline to animate the values that make the drawings.

I'm also imagining an output view, more complex than the current iframe+canvas, where you could build + edit shapes with a "baby illustrator" Sutherland Sketchpad :wink: interface, and see the graph change as you add and change stuff.

Dreamweaver was huge for learning code for me, because I could interact with code or html and see the changes in the other pane. Similarly Flash had vector/layer/timeline/code views, but they were less integrated.

A nice demo of drawing↔flow http://www.creativeapplications.net/ipad/sketching-dynamic-geometry-on-the-ipad/

So another question: how to bind a graph to edit it from another view.

[jonnor]

I think we will need this to avoid "blindly manipulating symbols" (ref Brett Victor). I have several usecases already:

For jonnor/noflo-cad#1 I want a vector path editor, very much like noflo-canvas (interop would be nice) For jonnor/microflo#9 I want an editor for showing and manipulting a simulated microcontroller with pheriperals For jonnor/finito#1 I want an interactive finite-state-machine editor

In addition to the card/fullscreen/half-screen locations, I really think we should have a way to put editors/custom visual components directly on canvas, as part of the graph. Or at least a good way for the user of establishing the mapping between a component (in the graph) and an editor (manipulating the component or the data of said component).

Should we allow the editors to use any HTML5 API? Or do we restrict it to the tech we (currently?) use for NoFlo UI, like react for elements on-canvas and Polymer for things around?

[jonnor]

As a pragmatic approach, we could first establish a simple internal plugin API for these editors. Each editor would live in NoFlo UI, register in the package.json or similar, and be included at build time. Loading would happen when the user instantiates an editor (perhaps implicitly by adding component which needs the editor? perhaps indicated by the IIP/port data type?). The intention woud be that after we get some experience with the API on different usecases, we can later allow component libraries to ship custom editors.

[jonnor]

A big question is how the UI editor shall interact with the graph (that is, how data will flow between them). The cleanest would be to have the editors produce one or more IIPs, I guess? And then potentially have specialized components in the runtime that parse/adapt such IIP/data into something more low-level for consumption by other parts of the graph?

[cwohlman]

We've implemented a simple form of custom editors associated with port types. It's fairly simple to check the port's type and then display a link to a custom editor dialog:

noflo-node-inspector.portToInput: function (port {
    ...
    switch (port.type)
      case 'object':
        portDef.inspector = "noflo-object-port-inspector";
        portDef.value = JSON.stringify(value);
        portDef.inputType = 'text';

and

        <template if="{{ port.inspector }}">
          <button class="edit-value" data-port="{{ port.name }}" data-inspector="{{ port.inspector }}" on-click="{{ showPortInspector }}">
            <i class="fa fa-edit"></i>
          </button>
        </template>

This works well with the legacy port api, since it allows us to specify any port type, then the editor can be associated with the port type.

This would work even better with the new port api if the type property was exposed in noflo-ui code, eg:

    switch (port.type)
      case 'http://schema.org/Person':
        portDef.inspector = "noflo-person-port-inspector";
        portDef.value = JSON.stringify(value);
        portDef.inputType = 'text';