JSON recommendations: GUID for contained data

Question

I have a client that uses JSON to represent objects. For instance:

var person = { fname: "John", lname: "Doe", nicknames: ["jake", "kevin"] } 

To edit these entries, we would like to include a GUID for each object. The GUID embed method has not yet been set. I am now thinking of doing something like this:

 var person = { _guids: { fname: "XXX", lname: "XXX", _nicknames: "XXX", /* This GUID corresponds to the nickname container */ nicknames: ["jake-guid", "kevin-guid"], } fname: "John", lname: "Doe", nicknames: ["jake", "kevin"] } 

If each element should be its own object, it would become extremely messy and would prohibit pure exchanges in cases where GUIDs are not needed. However, this approach also leads to the question of how to deal with something like this:

 var person = { _guids: { fname: "XXX", lname: "XXX", sacks_of_marbles: ["container-guid", "first-sacks-guid", ["XXX", "XXX"], "second-sacks-guid", ["XXX", "XXX"]] } fname: "John", lname: "Doe", sacks_of_marbles: [["red", "blue-with-swirls"], ["green", "pink"]] } 

Any recommendations on how to maintain cleanliness, lack of verbosity, and the ability to include a GUID?

Answer 1

In my opinion, the purest "identification strategy" is, firstly, the inclusion of only relevant identifiers, and secondly, the inclusion of these identifiers in the scope of the object.

In your case, I would be shocked to find out that fname and lname require their own identifiers. These are properties or attributes of one object or person record. person will most likely have an identifier, and the corresponding fname and lname should be easily identified by the person context:

 var person = { id: <guid>, fname: "Robert", lname: "Marley", nicknames: ["Bob Marley"] }; 

Or, if the nicknames attribute is actually a list of links, perhaps this is:

 var person = { id: <guid>, fname: "Robert", lname: "Marley", nicknames: [{id:<guid>,nickname:"Bob Marley"}] }; 

If for some peculiar reason each name is its own semi-independent record with attributes and identifiers, consider it as a fully qualified object:

 var person = { id: <guid>, fname: {id:<guid>, name:"Robert"}, lname: {id:<guid>, name:"Marley"}, nicknames: [ {id:<guid>,nickname:"Bob Marley"} ] }; 

Although the third example is not too confusing here, it is probably much more detailed than necessary. I would highly recommend taking off the first example and letting the context do the job.

Answer 2

You won’t get any cleanliness or lack of details if you enable the GUID for everything! However, one way would be to turn your property values ​​into hashes, for example

 var person = { fname: { value: "John", guid: "..." }, lname: { value: "Doe", guid: "..." } } 

This has the advantage that you can nest the GUID next to the corresponding values, arbitrarily deeply. However, this will also add some overhead for each access to the values ​​of the object (since person.fname should become person.fname.value , etc.).

Answer 3

After considering the suggestions here, as well as the use case, the following decision was made and seems to work quite well.

 var person_with_guids = { obj:{ type: "person", fname: "fname=guid", lname: "lname=guid", nicknames: ["larry-guid", "curly=guid", "moe-guid"], father: "nick-nolte-guid", }, refs:{ fname-guid:{ display: "Johnny", edit: "johnny" }, lname-guid:{ display: "Walker", edit: "walker" }, larry-guid:{ type: "person", ... } } } var person_without_guids = { fname: "Johnny", lname: "Walker", nicknames: ["Larry", "Curly", "Moe"], father: {fname: "Nick", lname: "Nolte"} } 

Without going too far into the specifics of the selection, the above scheme has the advantage that the resolving version of the manual must be translated by the machine into the sans-guid version. There will be times when a user-friendly, lightweight JSON is required, and in other cases where even a subtle difference between text text and editing text is required.

The same could be done using the schemes proposed above, turning everything into an object and inserting a guide into it. However, this leads to the fact that the guides will be included in the already nested system, which makes interpretation more difficult visually. To maintain a smoother view, the search table methodology was chosen.

Thanks to all who responded.