Separating presentation and data in applications an accepted design practice, but somehow it is not as common in-browser apps as it is on the server side.
Here's an architecture of a dynamic web app that works well for me:
- an app server exposes JSON and no HTML. (eg django or rails)
- html/css/js is completely static (eg. on S3/CDN) and defines UI as a set of HTML templates.
- once html/js is loaded in the browser, the browser makes an AJAX call to the server to get the JSON data
- in-browser JS expands a template, the data is rendered out
Clean, but what are you supposed to do with user agents which do not support JavaScript? Server-side templates still let you customize the page in that case.
Right, in this case client-side templating just moves to the server.
When JS processing isn't available on the client side, this same stack is moved to the server side. This way the same logical separation between UI and data is maintained.
Why does it need separate constructs for {.section} and {.repeated section}? You could take the absence of a key to signify "hide this section", its presence to signify "show it once, with these values", and its presence as an array to signifiy "show it multiple times, one per element". That's the way google-ctemplate works, and it seems to work quite well.
(BTW, I had no idea Google's templating library was an open-source project. Kinda fun to see that the stuff I work with daily isn't a proprietary walled garden after all. And some trivia for those who don't routinely Google project owners: it's written and maintained by Google's employee #1.)
This reminds me of Microsoft's first attempt at web scripting, before ASP. Can't remember what it was called, but for each final HTML page it had a template file and a database query file.
It turned out to be just too hard to do anything useful with it.
I made a light version of haml for javascript called baconl. It doesn't support embedded code, but I have found that it is not needed when used with most javascript frameworks.
Cool project. Much like Ruby, Python seems easy to match to JSON.
Also, check out JsonML : http://jsonml.org/ . The focus lies more on the client side templating (where it's all JS anyway), but it has additional goodies like XML-to-JsonML XSLT transformation.
Here's an architecture of a dynamic web app that works well for me:
- an app server exposes JSON and no HTML. (eg django or rails)
- html/css/js is completely static (eg. on S3/CDN) and defines UI as a set of HTML templates.
- once html/js is loaded in the browser, the browser makes an AJAX call to the server to get the JSON data
- in-browser JS expands a template, the data is rendered out
In this architecture, http://code.google.com/p/google-jstemplate/ is key. Check it out.