Open mirrexagon opened 7 years ago
Yeah, Edgy doesn't really know what types the node/edge attributes in the JSON are. When a graph is turned into JSON (for embedding in XML or exporting as JSON), the attributes are blindly turned into turned into strings using JavaScript's JSON.stringify
(hence when they are turned back, the list is no longer a List
, but a plain old Object
since there's no way to know what kind of object it once was). This problem extends to all Edgy types (such as other collections).
To fix this, we could write JSON serializers and deserializers for each Edgy type (which is probably too much work). Alternatively, we can start storing attributes in the graph JSON as their serialized XML representations (since there are already serializers and deserializers written for XML). Then there's the issue of maintaining compatibility of save files, etc. It might be difficult to keep everything working.
Unfortunately we don't have resources to implement the ideal solution of de/serialising etc, but we could consider a pull request if someone wanted to contribute this.
Got caught by this one as well. Should the ability to create new node/edge attributes be removed? As these new attributes do not behave "as expected" with respect to saving/exporting projects.
I want to store lists in node attributes. This works fine during a session, I can read and iterate through the list properly.
But when I save the project (or export it to JSON), then open it again (or import the JSON), the attribute can't be accessed as a list anymore. Using the say block on the node attribute gives "[object Object]", and the attribute can't be accessed as a list, giving errors like
TypeError: list.at is not a function
.Here's an Edgy project exported to XML that demonstrates what I mean: https://gist.github.com/mirrexagon/b3e97e0fe2f6027e8a7f26bbad9fc9fd