XML is Dead. Long Live JSON.
There's quite a bit going on at Rockall Towers right now, work-wise, which is giving me lots of excuses to learn about things I've always meant to, while getting paid to do so, as well as being able to pass the benefits on to you guys. Luckily for you I always seem to have an understanding with my customers clients that parts (although, only ever the underlying technology) of what we work on together will inevitably end up on this site. IPR rarely rears its ugly head. If a client ever did object to this I think I would probably turn the work down.
Anyway, I digress. Late last week I used JSON (in conjunction with Ajax) for the first time. And I like it. A lot!
If you've used Ajax with Domino you've probably done so using XML to send/return data to the browser. After all, XML did put the X in Ajax! Chances are the XML you used was generated by Domino following a ?ReadViewEntries command? Either way you might have found that working with this (or any for that matter) XML in multiple browsers, using JavaScript, is a pain. This is where JSON steps in and makes it all a whole lot easier.
I don't want to go in to to much detail right now, as I want to share the demo and write about it more in a full-on article. For now I will tease you with this demo application. Like the Name Picker demo from a while back this app also uses the data in the database you lot helped compile.
This JSON version works by passing the entered name to an agent, which then passes the name to the GetAllEntriesByKey method and returns all data as plain text in JavaScript Object Notation format. The browser then turns this text in to code using the eval() method. Not only is the data transport lighter than with XML, but, apparently, the code needed to work with the data is faster. Most importantly it's a hell of a lot easier to code the application for multiple browsers. In fact, due to the standard adoption of JavaScript in most browsers, it's almost impossible not to.
What surprised me was the lack of straight-forward documentation out there. Not only about using JSON with Domino, but JSON in general. This can be off-putting when JSON is just another acronym you're supposed to know about (JAAYASTKA?). Well, it was for my anyway. Hopefully my article/demo will show it's something to embrace while being easy to learn as well as a benefit to your applications.
JSON rules!!
Skip to the 
You can subscribe to an individual
Trumped again!!
I was just in the midst of an entry about using json to replace AJAX xml. I started with simple things like returning an object that simply performed a function, or returned an error to the client.
I used JSON in a map application in exactly the same way you are (agent/getallentries). I built a prototype in php and moved it to domino. It worked great in php. But because of the need for an agent, was slow in domino. The ReadViewEntries and XML approach, albeit more complicated, was faster than the agent with JSON.
My JSON feed of
[["1650450.39664552","-1950228.23368166","7107","BWI-Parkway","41935", 0],
["1373824.13000324","-2246882.14520136","7273","Jamestown-Falconer","42100", 0]];
is much easier to handle with eval() than processing xml from a view of longitude, latitude, site number, site name, etc. But the performance hit was too much.
Do you find that there's not a noticeable difference between rendering view data with ?ReadViewEntries and the agent? Or do you just accept the performance loss in favor of the implementation benefits? Or is there some other secret (servlet/agent manager tuning) that I'm missing?
Cool stuff though.
Sorry Jeff. Don't let this stop you writing it though!
Vince. The performance hit is an obvious drawback and whether or not it's acceptable depends on the situation at hand. If it were Google Maps it wouldn't do, but in my case it works fine.
The demo app doesn't seem so slow right now. Maybe I should do some timings though. I'll keep an eye on it today as well. Who knows? Maybe the server will end up crashing to its knees by mid-morning.
I'd thought about using a view to render JSON but we can't as there's no way to make sure each row is followed by ", " apart from the last row. Unless we did an @DBLookup and imploded them?
@jake: how about a little javascript function that replaces the last "," with ";"
Hi Jake,
Re: "I'd thought about using a view to render JSON but we can't as there's no way to make sure each row is followed by ", " apart from the last row. Unless we did an @DBLookup and imploded them?"...
You could create a "$$ViewTemplate" form for the View and hardcode the last element on the form after the "$$ViewBody" field. You would then need to add the "," at the end of each row in the view.
After that, all you need to do is to ignore the last entry in the results returned!
Later
Patrick
P.S. I have never tried using JSON, but the above should work...!
How about using a page instead of an agent...
Set the page content type so that nothing else is added by Domino to the output. For JSON, setting it to "text/javascript" would be appropriate. Then, add computed text to the page to generate the JSON--can't add fields since this is a page, but computed text works just fine in this situation. The computed text could be an @DbLookup, and could even make use of parameters passed in the URL (use @UrlQueryString inside the computed text to get the params from the URL).
Although it wasn't JSON, I've used this technique before, and it worked well. Seems to me it would just be a matter of getting the formula to pump out the right syntax for JSON. The other caveat is a familiar one: the computed text can't return more than 15K.
Question remains, would this be any better than an agent...
@Larry. Possible but seems a little perverse to me. Not something I'd like to do really.
@Patrick. Still a little perverse but less "hacky". We could add ", null}" at the end of the viewtemplate. Nice idea. Will give that a try.
@Rod. Likewise, nice idea. Will give this a try as well and see how they all perform against each other.
Cool. Yeah, I overheard a contractor from Aussie land last year saying just about the same thing: "X M L is D E A D." One of the demos Mark Barton published with me used JSON to handle login credentials. {Link} That's the nice thing about Ajax - you don't HAVE to use XML - any old plain text message of your choosing will do. Hugely useful. Now all I have to do is convince the WebService zealots here to ditch SOAP in favor of JSON.
here's a nice comparision between JSON and XML...
{Link}
I'm not sure about the 'dead' part of the title as I always look for vunerabilities in new techniques and at first glance, this reminds me of the csv/structured text nightmares that I've encountered in the past.
I ran into situations where there are both double quotes followed by commas in the data which crashes elegant solutions such this with great ease. Sprinkle in a bit of multilingual translation happening at the server and you're getting your dollar values back with a comma for a decimal point (French) and you're halfway there to the data error. That and in some medical scientific terms where the lay term is noted in quotes followed by the scientific term, with (you guessed it) a comma after the lay term. You might say that there should have been two fields, but this occurs in many comments fields.
I'll try it out with the double tilde character as a separaor and do replace function when it gets to the client, but I thought I would pass on this heads-up for those getting the warm fuzzys with the structured text feed.
@Michael
URL encoding is a great way to work around this. When marshalling an object. it's a good way to prevent breaking the transport mechanism to encode variables on the way in.
Java Reference: java.net.URLEncoder, java.net.URLDecoder
Javascript Reference: escape(), encodeURI, etc
{Link}
and unescape()
Hi Jake. I like JSON a lot too. I made some coding to generate JSON output from LotusScript and published on my site. Maybe someone find this resource useful: {Link} Congratulations for codestore.net, greetings from Spain.
@Rod:
"Set the page content type... ...For JSON, setting it to "text/javascript" would be appropriate."
Not strictly true. The accepted content-type for JSON is text/plain. Seems odd but there's good reason for this. What you return to the browser is text. It's not JavaScript until the code back at the browser runs the eval() method on the string.
At least that's how I understand it.
@Jake
Given my JSON experience (or lack thereof) I'll defer. Could be a moot point soon anyway: {Link}
and
{Link}
As for javascript itself, apparently "application/javascript" is now the preferred content type. Sort of. {Link}
Wait six months and it'll probably be different... ;-)
For those interested in JSON and Domino be sure to check out session AD401 at Lotusphere 2007.
Also, why wouldn't you use application/json?
Jeff, can you please mail me a sample database of using JSON. or share it with all your 'students' on your website
Impressive stuff ... i think a drop down like google suggest in domino works on same basis..