Gojs: multiple sections in one shape

GoJS
1

I am wondering what the best way is to implement a node with three separate sections (e.g., such as textBlocks) as in the picture below.

Also, if I click on the node, what is the best way to simultaneously access the properties associated with all the different elements of the node (so that if I wanted to add my own custom node editor, I could bring up all the properties that could be edited).

Hope the question makes sense.

2

Did you want the node to include the four colored rectangles?

If not, it appears to be either a “Horizontal” Panel or a “Table” Panel holding three TextBlocks. Each TextBlock would have a Binding on TextBlock.text to a property on the node data object.

3

In this case, no, the “container” (I’m calling it that to purposely avoid GoJS terminology) would contain three smaller “containers” where I would want to control the content of the sub-container and its size.

4

Something like this? https://codepen.io/simonsarris/pen/opJgLp

5

Thanks, looks like that is one way.
Another way is here in this codepen example, based off the textBlock example.

This brings up a question about margin and the Margin class.

If you wanted, e.g., a top margin of 10 and a bottom margin of 20, is there an example of how to set these specific properties? I experimented, but am I not understanding how to do this.

6

Looking at this further…
The “Horizontal” part in my simple codepen does not seem to allow for as many features as the more complex structure you use in your example, so the structure you are using is what I’m looking for.

The next question becomes: what is the best way of clicking on the “parent” and accessing all the properties of the “children”?

==============================
Completely changing the topic…
I wonder if part of the reasons grokking GoJS is challenging for me is due to the combination of all the “go” functions with object properties wrapped inside the functions, rather than a more JSON-like type of api?

Another way to put this: in chart libraries like Highcharts or AmCharts, you might have one library function that “makes” the chart, and then inside the function, you declare how you want things to look, etc., with a JSON structure. With GoJS, however, you have to keep calling $(go.Whatever, and maybe all the ceremony becomes distracting.

So instead of…

$(go.Node, "Auto",
    $(go.Shape, "Rectangle",
      { stroke: null },  // removed the name property
      new go.Binding("fill", "color")),
    $(go.TextBlock,
      { margin: 6, font: "18px sans-serif" },
      new go.Binding("text", "key"))
  );

…the syntax would be one “make a diagram” call with go, and inside you could use a (seemingly) simpler declarative syntax. Dummy example:

{
   nodes: [{
      type: "Auto",
      shapes: [{
         type: "Rectangle",
         stroke: null,
         bindings: [
            { "fill": "fillColor" }, 
            { "stroke": "strokeColor" }
         ]
      }],
      textBlocks: [{
         margin: 4,
         font: "13px sans-serif",
         bindings: [{
            "text": "key",
            "twoWayBinding": true 
         }]
      }]
   }]
}
7

If what has been shown above is only a single node, then it is the visual representation of a single data object which can have as much information in it as you like.

For completely different topics it would probably better to use different forum topics.

8 years ago we considered three different ways of building templates. What we chose was clearly the best in terms of compactness and flexibility.

It isn’t clear to me that using a JSON data structure to define the visual tree would be able to scale up as well. Consider the slightly more complicated node template in Org Chart Static. Or the variably structured nodes in UML Class Nodes, which are data bound to Arrays of data, each with their own templates.

In particular note the power of using JavaScript functions to organize and avoid duplicated JSON in defining the templates of Flowchart. That includes a nodeStyle function used in several node templates and a makePort function used repeatedly within each template.

Consider also the power of programmer-defined encapsulations for the buttons used in IVR Tree and defined in https://gojs.net/latest/extensions/Buttons.js.

None of the above features are possible when one is restricted to a JSON-like data structure description. The only apparent positive for using JSON to define templates might be the ability to save and restore templates because they are just data structures. Yet it turns out that no one needs that. And JSON is so much more verbose and cumbersome and limited than allowing the use of JavaScript.