Pretty interesting, and I've completed an exercise where I receive a JSON formatted reply and dynamically add the properties into the target DOM.
This was relatively straight forward.
However... chapter goes on to ask things like:
How would you avoid showing one of the properties returned?
How could you format the property key labels for better human consumption?
(an array of url strings are provided as values to a property...)
How to format as Urls so they are clickable (okay, I know how to create link elements so that isn't the problem, what the problem is...)
are there common practices on how to do the above steps dynamically? i.e., without having specific client side semantic knowledge of the JSON provided properties?
for example, item I could simply do something like:
but I don't necessarily want to know implicitly that there is a key named "id" that isn't for display purposes. And how a property called "description" should be rendered for a lable?
Is there a concept of a display map (something like what XSLT is for XML?)?
I could envision some sort of client/server interaction where I could download such a map from the server and apply it during the object rendering process?
Bear Bibeault wrote:To be honest, I'm not sure what you are asking for.
I'm sorry, I was trying to be clear...
so given some JSON text in response to my reply such as this...
I'm dynamically rendering it by doing something like this:
So... the bulleted questions I included in my original message refer to this process and JSON code format.
So using MVC pattern, this JSON code is the Model. Is there a best practices process for applying V(iew) rules dynamically?
How is the code supposed to know what to render if you do not give it the instructions?
You can make the code as smart as you want. Pass it a dictionary on how to render, give it the instructions dynamically. or just hard code it.
Joined: Jan 16, 2009
Eric Pascarello wrote:How is the code supposed to know what to render if you do not give it the instructions?
Therein lies the question, it would seem a nice addition to have a layer that can be applied (almost like a dynamic css) to the JSON to JScript object rendering process to separate out the view rendering rules.
I'm just saying... there must be some tricks to the trade here, I'm just hoping not to reinvent a wheel. And hardcoding, while possible, is a very poor design choice.
I'm surprised at the questions I'm getting about this. It wouldn't seem to be a new concept.
For me, I still don't think you are explaining what you are after very well. If you just want text/dictionary substitution, that's better handled on the server before the JSON gets transmitted in the first place.
I think I understand what you are wanting to do and I believe the way you are currently rendering your output is a bit of a bad practice. So let's forget the book exercises for a moment and just focus on how you should really be rendering this data from the server. Or rather, how I would do it. ;)
JSON is a great format when you need to return object data back to the client. But for the purpose of showing a bit of HTML, there's really no need. I would use a partial view which is to say maybe a JSP that will render your item details. Forget the fact that it is being rendered as a JSON response. Just code it like you would want to see it in a typical response fashion. Then simply use an ajax call to fetch this page. On the server, deal with localization and all that yuck yuck then the server will return the view as the response, which you can just shove into a container using innerHTML or some such method.
I find that I only need to return JSON data directly to the browser on very very special occasions. Most of the time, I am just rendering partial HTML that gets shoved into a container. So as far as best practices are concerned with regard to your problem, this I believe would be a better solution than returning pure JSON.
Yep, that's exactly what I did. I essentially created a mini meta language that mapped the property/value pairs to their types, localized display text (if applicable) and some other augmentations that allows my process to run with minimal knowledge of the server supplied data, other then to expect an "id" property that represents the head of the JSON object.
Anyway, I believe Greg has hit my issue on the head in his latest post. Problem I'm having is I'm running from static scripts for prototyping and sidestepping a major step that would normally be performed on the server. So while this has been a fun exercise, the JSP solution is most likely the better approach overall.