Using the TreeModel, all the node data is loaded and is visible by simply giving it the array of objects. Unfortunately, I haven’t had any luck yet getting GraphLinksModel to display the text inside each node, even though I can see most (if not all) of the nodes I’m expecting.
I’m putting the data as each node’s value, since I’ve only seen the examples where key value objects are pushed into the model’s data array.
Any suggestions?
The node templates and link templates are independent of the type of model that the diagram is using. So the same node template should work with the different models, assuming the node data is the same in both. (I suppose the data.parent property is likely to be different.)
In fact, one way of doing development is not to bother specifying any templates at all, first making sure that the page loads OK and that the models are loaded from the server and saved to the server correctly. Only then does one start providing custom templates, adding only what is desired to the appearance and to the behavior of each node and link.
The node and link templates are not getting changed here, and they already work as expected while using the TreeModel.
I’d get an error that data key isn’t a string or number if I were to simply use the same data array as I was with the TreeModel, though I’ll double check to make sure I’m not letting any undefined object through. For now, I’m making the GraphLinksModel use a data array consisting of objects such as:
{Key: arrayPosition, value: dataAtPosition}
So your node data in your TreeModel also consists of objects looking like:
{Key: arrayPosition, value: dataAtPosition} ?
I meant to respond yesterday, but no, the TreeModel only requires the dataArray and which node to use as the parent, without key value pairs to relate the nodes to the array of links that represent each connection.
It looked like:
{ nodeParentKeyProperty: ‘Parent’, nodeDataArray: objArray }
The whole GraphLinksModel looks like:
go.GraphLinksModel(newDataArray, linkArray)
while the newDataArray is almost exactly like the original except using the {key: position, data: objAtPosition}
I’m sorry, but I do not understand. Could you please show a very simple TreeModel’s nodeDataArray, and the equivalent GraphLinksModel.nodeDataArray and .linkDataArray?
In general I think you should be able to use the same nodeDataArray in both models. In the GraphLinksModel the “parent” property would be ignored.
TreeModel’s dataArray:
[{id, part}, {id,part},…,{id,part}]
GraphLinksModel’s dataArray:
[{key: 0, data: {id,part}}, {key:1, data: {id,part}},…{key: n, data: {id,part}}]
The keys are then used to relate nodes in the link array.
What is { id, part }? Could you please show the JSON-formatted text for both nodeDataArrays?
It’s the same in both.
Example:
{
id: 35,
part: “Wheel Well Bolt”
}
Where is the parent key property in your TreeModel node data objects?
So why isn’t your GraphLinksModel’s nodeDataArray like:
[ { id: 35, part: "..." }, { id: 47, part: "..." }, . . .]
I did not type out every element in the dataArray to save time, but each object is the exact same in both models (aside of using the objects in the data field for GraphLinksModel compared to simply the array of objects for TreeModel).
The objects do have a ‘parent’ element as well.
{
id: 35,
parent: 32,
part: “…”
}
Yes, Walter is pointing out that your data is different between the models, which will cause the bindings not to work the same.
It sounds like you have this:
TreeModel node data: { id: 35, part: "..." }
GraphLinksModel node data: { key: ..., data: { id: 35, part: "..." } }
So if your binding is looking at “part”, it can’t find it in the GraphLinksModel data since “part” is a nested data property. To see this, try evaluating myDiagram.nodes.first().data.part in the console. It will be undefined. Then try myDiagram.nodes.first().data.data.part, which is nested, and you’ll see the value.
I think your GraphLinksModel data should look like this instead: { id: 35, part: "..." }. Just make sure you set Model.nodeKeyProperty to “id”.
As a belated update: I got it working after I read jhardy’s response. Adding the extra element on top of the data was meant for use as the keys for linking nodes together since it was initially suffering from an error about not using an integer or string as a key when given the original data array; the data has several key elements that made sense logically, but were not used correctly to identify a node until it was explicitly set.
One way to think about the data in the Model.nodeDataArray is that you can imagine each data Object being a “record” or “row” from a “table” in a database. So the properties would naturally be flattened onto the one Object.
Then you need to make sure that all of the properties are needed and have the values that you expect.
Thinking of the Model.nodeDataArray and GraphLinksModel.linkDataArray as the JavaScript representations of relational database tables doesn’t preclude using nested Objects, but it’s just more work and confusion unless it’s coming from a different source.