toIncrementalJson points format inconsistency

Because our persisted data model for links is different from what GoJS wants, we have to manually update the points when there are midpoints. We do this on InitialLayoutCompleted. When there aren’t any midpoints and the user adds one, here is the incremental JSON where points is an array:

    {
    "class" : "go.GraphLinksModel",
    "incremental" : 1,
    "linkKeyProperty" : "key",
    "modifiedLinkData" : [{
            "parent" : "ext-comp-1228",
            "key" : "216:WPDS",
            "midpoints" : {
                "Na" : false,
                "o" : [],
                "H" : 0,
                "ec" : null,
                "Kj" : null,
                "fa" : null
            },
            "category" : "namedlink",
            "labelVisible" : false,
            "text" : "",
            "from" : "126:WPDS",
            "to" : "216:WPDS",
            "linkColor" : "#999",
            "tranVisible" : true,
            "strokeDashArray" : null,
            "points" : [135.2847602000331, 115.81426167116703, 210, 242, 377.0966295976506, 176.01825395374823]
        }
    ]
}

Now if there is an existing midpoint and the user adds another, points now comes back as an object.

    {
    "class" : "go.GraphLinksModel",
    "incremental" : 1,
    "linkKeyProperty" : "key",
    "modifiedLinkData" : [{
            "parent" : "ext-comp-1275",
            "key" : "216:WPDS",
            "midpoints" : {
                "Na" : false,
                "o" : [{
                        "class" : "go.Point",
                        "x" : 210,
                        "y" : 242
                    }
                ],
                "H" : 1,
                "ec" : null,
                "Kj" : null,
                "fa" : null
            },
            "category" : "namedlink",
            "labelVisible" : false,
            "text" : "",
            "from" : "126:WPDS",
            "to" : "216:WPDS",
            "linkColor" : "#999",
            "tranVisible" : true,
            "strokeDashArray" : null,
            "points" : {
                "Na" : true,
                "o" : [{
                        "class" : "go.Point",
                        "x" : 132.54668888700468,
                        "y" : 117.2503320708705
                    }, {
                        "class" : "go.Point",
                        "x" : 210,
                        "y" : 242
                    }, {
                        "class" : "go.Point",
                        "x" : 315,
                        "y" : 245
                    }, {
                        "class" : "go.Point",
                        "x" : 382.57772043949024,
                        "y" : 184.93091516489758
                    }
                ],
                "H" : 0,
                "ec" : null,
                "Kj" : null,
                "fa" : null
            }
        }
    ]
}

I don’t know if this is a bug or the way it’s designed to work but thought I would point it out. Personally I would prefer the incremental JSON to always be in the same format. I found a way to do this by changing link.point = List to link.points = List.toArray() when I manually set them.

I’m curious why you have both “points” and “midpoints” property values. It seems in your situation you really only want “midpoints”.

What you are showing looks like some debugger’s dump of the model objects, not what Model.toJson or Model.toIncrementalJson would put out. The reason I say that is that those two methods would not put out those internal property names of the List class for the “points” property – it would put out an Array of numbers. That’s shown in the first of your two outputs.

So although I’m not sure what’s going on, I think there is some inconsistency in your code that is producing those values. I think you should delete any existing Binding of the “points” property and replace that with the one that is currently on the “midpoints” property, using the “points” property name.

We only store midpoints in our database whereas GoJS wants start, midpoints, and end point. We take our data and create the midpoints on the model. Then we calculate the start point and add it to points, add midpoints if they exist, then calculate the end point and add it to points. points in the model is 2-way bound to points in the Link. So midpoints is not bound to any Link properties.

Changing Link.point to be bound to midpoints causes just an arrow head to be drawn at the midpoint with no lines because there are no start and end points. Is there an option for Links to auto-calculate start and end points? If so then we wouldn’t have to map data both ways which would be awesome.

The output from above is all from this line of code:

    Ext.log('    ' + e.model.toIncrementalJson(e));

Well, I still don’t think it makes sense to store two very related collections of points on the link data in the model. Seems to me you could have a Binding on Link.points to data.points where the value of data.points is a List of Points that only includes the middle points, not the end points.

Model.toIncrementalJson would write out an array of numbers.

If the second output was indeed the result of calling Model.toIncrementalJson, that’s odd. I would guess that the value of data.points is a List but not of Points. I.e., a List that was constructed without passing the Point class as the only argument. I don’t know how that happened, though. Clearly some code set that data.points property, but I don’t know which code.

So here is the different between midpoints (our data) and point (what GoJS wants). If there is a way for GoJS to just use our midpoints without having start and end points then please let me know how. It would be nice to not have to convert back and forth. 2 1/2 years ago when I got started I was told this wasn’t possible but maybe it is now.

midpoints - [M, M, M]
points - [S, M, M, M, E]

Adding the type fixed the toIncrementalJson problem. Thanks for that tip.

            newPoints = new go.List(go.Point);

@walter You said that you don’t see a reason to have both midpoints and points in our model. Can you respond to my post above if GoJS supports only having midpoints for links? If you then we have to continue to map points <-> midpoints.

Thanks

If it’s working reliably for you, then I suppose there’s no strong reason to change it.

You have already done a lot of the work to adapt the slightly different notions of what points are used in the link route. I just guessed that the code could be reorganized not to leave the whole route kept on the link data. Sorry, I don’t have an example implementation for you. Although I think you’re not the only one with this kind of expectation, so maybe we’ll think about making that an option in the future.

3 posts were split to a new topic: Changing precision of points in model