Treemodel Initial Node Positioning for orgChart Editor

Hi,

I am using GoJs to rewrite a feature in my web app. I am following along with the orgChartEditor sample. The problem I am experiencing is with the following diagram model:

{
"class": "go.TreeModel",
"nodeDataArray": [
    {"key":1, "name":"Stella Payne Diaz", "title":"CEO", "loc":"695.48, 0.00"},
    {"key":2, "name":"Luke Warm", "title":"VP Marketing/Sales", "loc":"111.70, 111.50", "parent":1},
    {"key":3, "name":"Meg Meehan Hoffa", "title":"Sales","loc":"118.35, 223.00","parent":2},
    {"key":4, "name":"Peggy Flaming", "title":"VP Engineering", "loc":"1091.25, 111.50", "parent":1},
    {"key":5, "name":"Saul Wellingood", "title":"Manufacturing", "loc":"848.75, 223.00", "parent":4},
    {"key":6, "name":"Al Ligori", "title":"Marketing","loc":"485.00, 223.00", "parent":2},
    {"key":7, "name":"Dot Stubadd", "title":"Sales Rep", "loc":"0.00, 334.50", "parent":3},
    {"key":8, "name":"Les Ismore", "title":"Project Mgr", "loc":"727.50, 334.50", "parent":5},
    {"key":9, "name":"April Lynn Parris", "title":"Events Mgr", "loc":"485.00, 334.50", "parent":6},
    {"key":10, "name":"Xavier Breath", "title":"Engineering", "loc":"1333.75, 223.00", "parent":4},
    {"key":11, "name":"Anita Hammer", "title":"Process", "loc":"970.00, 334.50", "parent":5},
    {"key":12, "name":"Billy Aiken", "title":"Software", "loc":"1212.50, 334.50", "parent":10},
    {"key":13, "name":"Stan Wellback", "title":"Testing", "loc":"1455.00, 334.50", "parent":10},
    {"key":14, "name":"Marge Innovera", "title":"Hardware", "loc":"1333.75, 436.00", "parent":10},
    {"key":15, "name":"Evan Elpus", "title":"Quality", "loc":"848.75, 436.00", "parent":5},
    {"key":16, "name":"Lotta B. Essen", "title":"Sales Rep", "loc":"242.50, 334.50", "parent":3}
  ];
}

has the location binding set via the loc attribute of the model, it is not set initially to go to that position. The expectation is when the data is loaded from the database the initial position of the node will reflect the database attributes. I added the binding property as the following.

...
// new code for the binding that I added for nodeTemplate.
new go.Binding("location", "loc", go.Point.parse).makeTwoWay(go.Point.stringify),

I noticed when I was testing the GraphLinksModel example, just adding the new binding similar to the above code and loc data in model sufficed for it to work. Am I missing something in the TreeModel? I am trying to justify using this product and considering purchasing the license for getting the production version.

Thanks,
mohammadzbggo

The Org Chart Editor sample, Org Chart Editor , depends on the Diagram.layout, a TreeLayout, to automatically position all of the nodes. The layout automatically happens after a node or a link is added or removed or changes visibility, or if a node changes size. In this circumstance there is no reason for node location information to be in the saved model.

Another common design is to have each node be located based on saved information in the model. The most common way to do that is by using a Binding on the Node.location property. The binding that you quoted saves the location as a string on the data.loc property of each node.

In this case the Diagram.layout is not needed. If your model data will always have valid location information on all of the node data objects, then you can just delete the setting of Diagram.layout in your initialization of your Diagram.

But if that might not be the case, then you can disable the layout by setting Layout.isInitial and Layout.isOngoing to false. That prevents automatic layout invalidation and thus prevents the layout from running. Then if you detect that some or all of the node data do not have valid location information, you can explicitly call Diagram.layoutDiagram with a true argument to perform the layout even though isInitial and isOngoing are false.

So it looks like Diagram.layout which in the case of the orgChartEditor is a TreeLayout doesn’t need the location data as it automatically handles the position to make it appear as a TreeLayout. That’s good to know.

So the removal of Diagram.layout is necessary for what I want to achieve. Yeah that worked, thank you very much. I’ll definitely get the support and the production version.