Rules for JSON?

[jkurrle]

Is there any specific set of rules or techniques for building JSON reports? I've been developing my own, as I've had to output some pretty complex reports the last week or two. So far, I've discovered the following methodology, when writing reports to be encoded with json_encode();

General Rules:

1) If you don't want to encase a number within quotes, cast it as an integer or a double. Example: $array[1]=(integer)$val;
2) If you want to associate one value to another, set an array key to match the value. Example: $array[bob]="fred"; will equate to JSON code "bob": "fred"
3) If you don't want to associate a value to a value in JSON, use array_push() or array_unshift() to push the value to the bottom or top of the array.

Methodology:

Because json_encode() processes multidimensional arrays, you must build the array structure from the bottom up. In other words, identify what are your lowest building blocks, whether arrays or raw data. Compile them into arrays, then work on the next higher level of arrays, using the data you just compiled. Keep doing so, until you reach the final top_level array, which is when you use json_encode().

This is just some general guidelines I've personally developed, but I was wondering if there are more specific guidelines or rules out there...

[Weedpacket]

Well, it's like building any data structure, really.... How you build it up depends on whatever is the most lucid approach. Whether you do it in a bottom-up approach as you describe or you start with a top-level "generate_report_structure()" function which sets of a whole cascade of functions that assemble parts of the report by calling other functions and assembling the subparts they return ... well, it depends.

One thing you mention which is certainly relevant is that JSON encoding the structure comes - like other serialisation mechanisms - at the end of the process, when you've got everything together. Before that point it would just get in the way.

[jkurrle]

I really don't see how your top-down method is going to work. The top mechanism is still calling submechanisms and so forth, which is still has to build it from the bottom up. The only difference I see is that the call originates from the top level. This just seems to add an extra layer of complexity to me that may not be necessary.

The only way I see a top down method is where you are accessing the sublevels more directly like thus:

$array[$array2[$array3[bob]]]='fred';

I can see this as a possibility, but for me to keep track of something 4 to 5 levels deep seems like a mental gymnastics workout! Sorry, but this mental couch potato will do it from the ground up. :-)

[Weedpacket]

Then .... I don't know what you're asking about. Are you asking how to structure data?

jkurrle wrote:

This just seems to add an extra layer of complexity to me that may not be necessary.

It means that no component needs to know the details of how any of the other components work. Which means that when I'm working with a given component I only have to think about that component and let the rest look after themselves.

jkurrle wrote:

but for me to keep track of something 4 to 5 levels deep seems like a mental gymnastics workout!

That is why we have computers - they're better at that sort of thing.

[jkurrle]

It took me a few times rereading all our posts before I realized what you were talking about, in terms of a top down approach. It appears that you would have preset functions or methods that compile the lower level data arrays, abstracting out the individual components, and also at the higher level layers. In my case, I'm not sure I have that luxury yet, as all my reports so far appear to be using different data sets from each other. For now, a bottom up approach seems to be more efficient for me...

[benardbert]

Thanks for the information you have shared.It is really informative.

uk fast