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

Allow option objects of any Umple model to be serialized/deserialized to/from Json #1067

Open
TimLethbridge opened this Issue Jul 13, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@TimLethbridge
Member

TimLethbridge commented Jul 13, 2017

It would be good if any object had a String toJson() method that would generate (serialize) a Json representation, and a fromJson(String) static method that would instantiate (deserialize) the object.

Since this would not be needed in every single model, my suggestion is to only generate this if -s Json is specified as a suboption on a generator.

A complication is that Umple has dates and times as primitives. We would need to use ISO8601 format. See https://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx
and
http://blog.plataformatec.com.br/2014/11/how-to-serialize-date-and-datetime-without-losing-information/

Note that Umple already has a Json generator, but it is for a representation of the model, not the instances of the model. See Generator_CodeJson.ump

Also Umple has a parser for Json. See Json_Code.ump.

For serialization, associations should probably become arrays. But some mechanism for dealing with cycles would be needed.

For the deserialization, it would seem necessary to be able to call the deserialization of associated objects, and again how to deal with cycles would seem necessary.

In both the above cases, it would seem that perhaps an objectID ought to be stored in the Json, so the same object encountered twice would result in any other attributes being stored.

@Nava2

This comment has been minimized.

Show comment
Hide comment
@Nava2

Nava2 Jul 13, 2017

Member

Java 7 (8?) added the javax.json packages. If each generator provides it's own solutions, that'd probably be best.

Solving recursive models requires some form of "cached" identifier, the objectId approach is how Jackson solves this.

Just saw this issue in my github feed, thought I'd add some info.

Member

Nava2 commented Jul 13, 2017

Java 7 (8?) added the javax.json packages. If each generator provides it's own solutions, that'd probably be best.

Solving recursive models requires some form of "cached" identifier, the objectId approach is how Jackson solves this.

Just saw this issue in my github feed, thought I'd add some info.

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