Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lists stored in node attributes are not loaded correctly #438

Open
mirrexagon opened this issue Apr 20, 2017 · 3 comments
Open

Lists stored in node attributes are not loaded correctly #438

mirrexagon opened this issue Apr 20, 2017 · 3 comments

Comments

@mirrexagon
Copy link

mirrexagon commented Apr 20, 2017

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

@cyderize
Copy link
Contributor

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.

@stevenbird
Copy link
Contributor

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.

@gregbreese
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants