Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Displaying JSON content

I am storing some data just as a json string.
The content is created and edited via a web page so I'm just storing the json for passing back and forth via http.

Now there is a requirement for the internal desktop users to view the content for reference only. There is no need nor should there ever be a need for them to edit this data.

I've started by parsing the json, merging the contents with an existing word doc, saving it as html and then just displaying the resulting file. This technically works but there's a lot of content I'm still to get to and was just wondering if any one knew of a more direct way to display the content of a json string?

Comments

  • I can't say I know of any way to shortcut what you are doing, but I am also curious as to what the final format looks like. Does it need to be pretty? Is a stringified view of the JSON not sufficient?
  • Maybe not overly pretty but it is a web based replacement for what is currently a formal document.
    The screenshot is the proof of concept while I figure out whether to go that route. The remainder of the document is somewhat more complicated so I figured I'd ask the question before I delved too much further into it.

    I expect at some point down the track someone will want a hard copy as well though that's not yet on the list.
    Creating a html doc that could then be sent to the browser if need be would more easily take care of that.
  • edited March 2018
    Okay, this is a form. I was thinking you were creating something more simplistic...like a property/value panel. This changes my perspective.

    I'd like to go back to your original question. You asked for a "more direct way to display the content of a json string". When I read that I thought you were asking for a utility that would automatically parse the JSON and display it in a presentation ready format (again, simplistic but in HTML so it would render well in a browser). You are really creating what a web or mobile app would normally do with the JSON: format it into respective fields.

    You also said "there's a lot of content I'm still to get to". I guess I'm not sure what this means. Perhaps it would help me to understand how you are determining the format of the HTML. Is this under your control or were you given a layout to follow? If you are determining the layout, how are you determining the position of the form fields?

    Sorry if I am missing the real point to this. But how I would approach this would be to design the form layout first and then I would write a utility that populates the form automatically. You could create your own schema (of sorts) that drives the utility. I've kind of already done this with an application I'm supporting. It takes a JSON formatted payload and populates a screen using defined positions. I used to hardcode this but it made more sense to softcode the format information using my own JSON-based schema like so:

    { "MVPRFields" : { "Action" : { "Column" : 20, "Row" : 3, "Length" : 1, "Justification" : "L", "Padding" : "", "CanAdd" : false, "CanUpdate" : false }, "Dealer" : { "Column" : 44, "Row" : 3, "Length" : 4, "Justification" : "L", "Padding" : " ", "CanAdd" : true, "CanUpdate" : false }, "County" : { "Column" : 68, "Row" : 3, "Length" : 1, "Justification" : "L", "Padding" : "", "CanAdd" : true, "CanUpdate" : false }, ...

    For something like an HTML form, I might create the HTML template and use replaceable parameters so I would just loop through the JSON name/value pairs and use a SWAP statement for each parameter:
    Swap '%' : FieldName : '%' with FieldValue in HTML
    Apologies if this isn't addressing your main issue.
  • Always happy to hear any and all suggestions. Never know what might trigger what.

    The web entry/edit form exists and is working. The layout of that form was based on an existing word document.
    The content had no direct relevance or purpose in the existing desktop app. It was a nice add on for their clients for whom the web/mobile front end was primarily created. This is why the content was just stored in the db as a json string. It just needed to be sent back and forth over the web.

    Now that it is in the db though, the desktop users want to be able to read it. They won't be using the existing web front end because it serves a completely different purpose for different types of users.

    I was going to use oipi and produce a pdf. Then I thought it might save me some time by taking a copy of the original word doc and making it a mail merge and that way some administrator can always format how they want it. So I started. Then I thought but that would leave a document open for editing. Then I thought, maybe I could save it as a html doc and send it to the browser. That seemed to be fractionally quicker then actually making word visible post merge. Then I thought why don't I just ask if anyone else has any other ideas.
    there's a lot of content I'm still to get to"
    The screenshot just shows the beginning of the document and the part that I have completed the code for.
    The remainder of the document is not as simplistic as what you see so the parsing code will be more involved and I'll have to learn how to merge tabular info within word if I continue this approach. Can be done of course but don't want to waste my time if there's a better way.
Sign In or Register to comment.