Creating a CQ 5.5.x ClientContext Compatible JSONP Servlet

Creating a CQ 5.5.x ClientContext Compatible JSONP Servlet

The bulk of what needs to be done for creating a JSONP servlet isn't much different than creating a POJEES - 'Plain Old JavaEE Servlet'.  In fact, the servlet I created ran under Tomcat 6.0.38. So we wont cover any of the Servlet method names implemented/overridden or configuration of the Servlet.

The first problem I had was figuring out what the content type should be.  This took some digging, but the following header finally got the CQ ClientContext to recognize the JSONP response:

response.setContentType('application/x-javascript');

The sources I found did not all agree on a value, but this value does work.

Then what I found was that when the ClientContext would request the data the first time, it worked fine.  But afterwards every single subsequent request failed.  I changed the URL of the service, and the same behavior: first request OK, all subsequent ones failed.  Obviously there was some kind of caching or something going on.

This is by no means an exhaustive, or even cursory explanation of why these headers 'fixed' things.  These comes from the 'make the damn thing work' department.  Also, I am not sure if ALL of them are required.  My suspicion is that they are not all required. But it worked, so I left them in.  Here they are:

response.addHeader("Cache-Control", "no-cache, no-store, max-age=0, must-revalidate");
response.addHeader("Pragma", "no-cache");
response.addHeader("Last-Modified", new Date().toString());
response.addHeader("Expires", "Fri, 01 Jan 1990 00:00:00 GMT");
response.addHeader("Connection", "close");

The last thing - or really it was the first thing - was the JSON Formatting.  This data was meant to be User account information. I actually built this part first because it was the easiest and most well known.

Thanks to a litle explanation by Justin Edelson, the URL on the ClientContext page (which I am sure I have overlooked a thousand times) is a real and functioning URL.  Take a look at the following page:  http://cqhost:4502/etc/clientcontext/default/content.html.  Add a JSONP datastore to the configuration, then right click and edit. Under and to the right of 'JSONP Service URL' you will see the URL: http://api.wipmania.com/jsonp?callback=${callback}.  Stick that in your browser and view.  This is what I used to figure out how to format my JSON appropriately.

In my case, I scoped a bunch of stuff: addresses, phone numbers, etc.  In other words I did not use a 'flat' structure.  But I guess either works depending upon your application.

One more thing I forgot about till I wrote this post. This problem had me ready to pull my teeth out.  

ClientContext rather than allowing 'you' to select a JavaScript function name for the callback, picks one itself.  It uses part of the hostname of the JSONP service for the JavaScript function name.  So, the CQ instance I was using (fairly common for local development) was http://127.0.0.1:4502.  ClientContext parses the hostname to pick out the function name.  In this case the JavaScript function name turned out to be '1' - which is NOT a valid JavaScript function name.

OK, so I chose kelleher.com.  FAIL!  The JavaScript function name it chose was 'http://kelleher'.  Not such a good JavaScript name.  The hostname MUST be a 3 dotted name host like: home.kelleher.com.

So, now that I have come to the brink of jumping off the Skyway bridge trying to figure this stuff out, enjoy the Juicy ClientContext / JSONP tidbits of arcane knowledge.

Share this post

0 Comments

comments powered by Disqus