JSON format for layers (groups)

[forresto]

Before I work on flowhub/the-graph#43 much more I'd like to nail down the JSON format.

If we follow the convention of processes, then graph.groups should be an object.

For hierarchical organization and autolayout noflo/noflo-ui#53 , it would be better if each node could belong to only one group. So

node.metadata.group: groupKey

group.metadata.parent: groupKey

[bergie]

@forresto if we want to have nodes belonging only to a single group, we can constrain that on UI level. Typically with groups you want to be able to have a many-to-many relationship, so that is what we have on JSON level

[bergie]

Here is the original groups format ticket: #62

[forresto]

Seems easier for things to match between JSON structure & UI. If groups are tree-like layers, then I'd vote for a change. If groups are many-to-many tags, the current system works, but seems less useful in the UI.

We need a flat representation of a tree. Groups need a unique key in order to nest them inside each other. How should this work?

{
  "name": "countdown",
  "id": "g_countdown",
  "nodes": ["interaction/ListenMouse_1u0rk", "strings/SendString_zry4n", ...],
  "metadata": {}
},
{
  "name": "save",
  "id": "g_save",
  "nodes": ["core/MakeFunction_t17n", "core/Split_xyb8x", ...],
  "metadata": {
    "description": "click save, run countdown, make jpg from canvas",
    "parent": "g_countdown"
  }
},

... seems fragile.

If groups were an object:

"g_countdown": {
  "name": "countdown",
  "nodes": ["interaction/ListenMouse_1u0rk", "strings/SendString_zry4n", ...],
  "metadata": {}
},
"g_save": {
  "name": "save",
  "nodes": ["core/MakeFunction_t17n", "core/Split_xyb8x", ...],
  "metadata": {
    "description": "click save, run countdown, make jpg from canvas",
    "parent": "g_countdown"
  }
},

... we could also take nodes out of the groups and each node could have the group id in metadata.

[forresto]

For many-to-many groups, a metadata.keywords array in the process would be a better mapping.

[bergie]

I'd start with what we have now, and consider changes only if necessary

[forresto]

That's what I'm doing... groups need an id to reference a parent group so they can be hacked to work hierarchically in the UI.

Should I make a new layers object that works as I need?

[bergie]

@forresto I'd try to avoid tree structures as long as possible

[forresto]

Explain?

They are required in some form to do collapsable groups with autolayout.

Also for the photoshop layer style view.