I recently had to connect a .NET desktop application to a web service that was built using Pyramid. My first thought was to use JSONP. However, JSONP is only useful for small amounts of data…and I had a lot of data to send/receive. Obviously, communication via an XmlHttpRequest with JSON was not an option due to limitations imposed by the Same Origin Policy (ref: http://en.wikipedia.org/wiki/Same_origin_policy).
In the end, we chose to use our existing Mako template infrastructure to render XML that the .NET clients could consume. If you’re a .NET developer, then you know that XML parsing in .NET is superb, which is why we went with XML rather than JSON over HTTP.
On the Pyramid side, there were really only 2 steps:
- Create Mako templates that would render XML
- Set the content type to text/xml
Render XML with Mako
This step was easy, we just created templates that use XML instead of XML.
<?xml version=”1.0″ encoding=”utf-8″?>
<companies>
% if companies:
% for row in companies:
<company>
<id>${row[‘id’]}</id>
<name>${row[‘name’]}</name>
</company>
% endfor
% else:
${result}
% endif
</companies>
Set the Response Content Type
This was also a very easy step. We just set the content_type immediately before the call to return. Importantly, the code below causes Pyramid to return the XML template with a content type of text/xml rather than the default text/html.
request.response.content_type = “text/xml”
return {‘companies’: companies}
Summary
Rendering XML with Pyramid and Mako was exceptionally simple. You can reuse the same view and url, and simply change the the template based on how the view was called.
One last note. You’ll notice that one negative side effect we have not corrected for is the use of \n\r in the rendered XML. This of course bloats network traffic, uses more memory on the client-side (if you’re using a DOM parser), and is all around crappy for all but the smallest of files. Next step will be to create some type of processor to eliminate the newline character.
