You are currently browsing the monthly archive for October 2009.

Surprisingly for a lisp programmer I’m enjoying developing iPhone apps.  My clients Melbourne GigGuide app is doing well and I’m much happier after moving from XML to JSON format for my data feeds.


Objective-C is simpler than C++ and closer to a scripting language in some ways.  The UIKit api itself is well designed, despite having verboseMethodNames.  This isn’t so much an RSI problem – the XCode editor does a nice job of guessing and auto-complete, while being non-intrusive – but its a lot of text to read which tends to obscure the idea behind the code.

Deeply nested JSON trees

Today I found myself chaining down a few levels of nested json objects, and decided I needed a much shorter syntax.

Many scripting languages have an associative array lookup syntax like someMap[“key”], and these can be chained.  In Obj-C, to access an NSDictionary you use objectForKey:@”key”.

at() Hack

I wanted something shorter so wrote this small hack  –

id at(id ob, NSString* k)
 if (ob && [ob isKindOfClass:[NSDictionary class]])
     return [ob objectForKey:k];
 return NULL;

Now I can index down several levels into a json tree easily, like this :

id obShops = at(at(at(json, @”Boutiques”), @”London”), @”EastEnd”);

Not as succinct as square brackets, but saves a lot of typing… enjoy

I wanted to vocalize some thoughts about secure mashups, after watching Douglas Crockfords 2007 google talk on the subject – Gears and the Mashup Problem.

Doug wrote the book ‘Javascript the Good Parts’ which has really pushed everyone forward to understand the powerful features of the language such as dynamic typing, lexical scope ‘closure’ and functions as first class objects.  JavaScript at its roots is more like lisp than Java and thats a good thing, although there are some bad parts to avoid.  He also discovered JSON, which has become the default data format for the web, saving us daily from the syntactic hell that is XML.  He has certainly earned the nickname of ‘Yoda’ in the JavaScript community.


I say ‘Yoda discovered JSON’ because I recall implementing a similar format, a decade or so ago, to solve a problem for a telecomms company I was consulting for.  In this case we wanted to send config settings between the fat GUI client and the back-end server system.  The config was naturally tree structured.. the kind of thing at the time people put in windows ini files [an ugly data format if ever there was one].   At the time I was ignorantly unaware of functional programming languages such as lisp and hence knew nothing of S-expressions [sexp on wheels!].  I was also wondering if the new XML would become a passing fad, and was deeply suspicious of Microsoft’s proprietary non-standard looking, tightly COM-bound, vendor locked-in XML api.   Anyway,  I forged ahead and wrote a nice little grammar, coded up a parser using lex and yacc, and never looked back.

Like every experienced programmer, Ive used SAX2 and dom parsers for XML in several languages. But it always grated on my sensibilities, the simplicity of the thing was hidden beneath ham-fisted verboseness. This feeling was largely subconscious, until the time I wrote more than a couple of pages of XSLT, and the ugliness of the approach slapped me in the face – not only was I hiding my data in an arcane dogma of syntax, but I was trying to write _programs_ to transform them in this nonsense!  It was the height of bad taste, so when I happened upon JSON it just felt like the right way to phrase tree data as text.

JSON is lightweight and terse – trivial in the best sense.  Theres no surprise that its had such incredible uptake among web programmers over the last couple of years, as its all the good parts of XML with none of the pain.

Mashups are Insecure

Doug talks about the main problem we have with web development today – Security, we have none!.

The default web development platform of JavaScript plus JSON plus AJAX, has been phenomenally successful to the point where we have interactive web page widgets we can drag and drop to compose our own user-customized pages in real-time : true web ‘mashups’.  Just take a look at the modularity of facebook as an example, or the ubiquity of google map widgets on individual web sites.

The problem is that any JavaScript widget can read and write any other widget on the page – a real issue if you have your stocks or bank widget embedded in the same page as a faulty or malicious world clock applet.

In his talk Doug suggests we need to isolate widgets into ‘vats’ containing JavaScript and DOM, and allow only JSON messages to flow between them, via a page-broker.  Each widget would be able to write to its own local DOM, to achieve its gui and interactive effects, but not be able to read or write contents within another vat.

As well as being a natural security boundary, Vats could also be a great way to scale performance – each Vat could run in a seperate thread using a CPU core, while keeping the current JavaScript programming model of a single execution thread.  Dougs talk was really a call-to-arms to get Yahoo, Google, Facebook and browser organisations to work together and make this happen.

Widget API

In other posts Doug has recommended some of the mechanics to achieve secure mashups via vats – JSONRequest(), the <module> tag, and send() / receive() api for json messaging.  In the Vat model the browsers would have to implement the page-broker and the module tag.  That requires agreeing to a simple and implementable API that can be rolled out and adopted gradually.

A new API also means defining a formal standard, and this just never seems to work unless there is already a defacto-standard implementation that has some market adoption. History tells us that you just cant get an api right without implementing a workable system first, and having people use it.  History also tells us that standards bodies never get anything done, and that you cant get 5 people to agree on an API, let alone 25.  The way forward is to implement something imperfect, then standardise what works.

I googled the web for ‘secure web mashup’ to see if there had been any progress since Dougs 2007 talk.  The answer seems to be ‘not so much’.  I did find an API for secure mashups by and some dojoX work, there might be others out there I simply dont know of [send me an email if you know of any]. are tackling secure mashups with their OpenAjax Hub 2.0 spec.  This was just released so I wonder if anyone is using it yet.  Their Managed Hub api looks to me to be too complex.  We need the absolute minimum that will enable messaging and allow for a good improvement in security – I just cant see this being adopted by busy programmers.

We need a solution.  We need it yesterday.

Page Broker as a service

Once we have a working API, that emerges as the defacto standard, there will still be a long rollout time.  People slowly turn over the version of their browser, often when they upgrade their OS, roughly every 2 to 3 years I guess.  For people with old browsers, it would be ideal if there was some partial migration option.

One idea I had is that the page-broker could be run outside the page as a separate process.  That might not enforce such good security but it might enhance security and allow Widgets using the new API to work in old browsers.

The widget module API would be something like module.send(json) and json=module.recieve() where all inter-widget and widget-to-page communication is via json text messages.  We could then stay API compatible and have widgets on one page talk to widgets on another page on another computer ( widgets talking Peer-to-Peer ).  We could have a trusted Page-Broker run on a server or even locally for faster performance.

Having the page-broker serve up some data publishing what widget services are available, and mediating messages between widgets seems like a model in the spirit of the internet.  Its implementable, nicely isolated, scalable and you get offline mode easily by running a local web server.  You can also publish non-GUI capabilities, such as data storage [CouchDB would play well with this setup]

I realise an out-of-process Page-Broker might not be the final form – we likely have to change JavaScript and the dom to enforce security.  But it does seem a really good interim setup for experimenting with, while the new browser features are being rolled out over time.


xilla tags generates HTML tags from PHP.

I found my code tends to be more readable using this approach. It has a mildly lisp flavor, and results in nested PHP code that looks something like this –

     tr("", array(
          td(array("class"=>"field"), "Name"),
          td("", "Jim Blinn"))));

As you can see it uses tag functions to build up a tree of PHP native arrays, which is then rendered using render_tags().

See the previous post for an overview and comparison with another tags library, HAML. The main difference is that HAML is a parsed syntax, whereas xilla tags is native PHP.

BSD licence, on google code here –

A while back I did some work in scheme lisp and was much impressed by the readability of the code which generates the HTML – basically a nice nested tree of self closing tags, where you can build up levels of abstraction, yet stay close to the exact HTML your rendering and have control over it.

Then I had to go back to PHP for pragmatic reasons, and I just didn’t gel with any of the frameworks or tag libraries around. I experimented with various template engines but it seemed annoying to break syntax and use yet another language. I did find an implementation of lisp in PHP, which I though was nifty, but the people who hired me as a consultant were eagerly awaiting their code bundle in PHP.

PHP just wont die. It may not be an elegant language but its the workhorse of the internet.

I had to find a way to close tags automatically and keep everything readable. There’s a lot of bad PHP code around, where the script basically progresses from the top of the web page downwards, mixing php code snippets with HTML, javascript and SQL statements – not a recipe for clarity.

The nested xilla_tag functions build up a tree built with PHP arrays.  This tree is then walked and HTML tags generated when you call render_tags().  As the tree is written out, the end tags are automatically added, and the resulting output indented.

Example Comparison

To make a valid comparison, I use the same HTML sample given in another tag library, namely HAML – see

Compare ‘Old school’ PHP program code –

non lispy php code

To lispy php code using xilla tags. Read from the bottom sample_page() upwards –

lispy php

lispy code body


I’ve uploaded xilla_tags to google code. You can use it freely under a permissive BSD licence – available on github here.

I hope you find it a more readable way of generating your web page programs in PHP,