You are using the wrong #templating system for #html.
Use javascript + json + DOM for html templating.
Front end developers know how to use this technology. They know this technology very well, so will be way productive.
No weird new template language to learn and install on every single project.
No dependency on a rapidly changing server side backend... or database, or 3rd party API required.
No taking the html, and turning it into [$%%WEIRD TEMPLATE LANG%%$$] step. Instead you can use javascript, json and the DOM.
Being able to use the templating system either via the browser, or via the server side means there is no dependency between the front end and the back end. Front end developers just need an example json file to work from. Then the back end developer just needs to create the json file.
It does mean you are dependent on a DOM+javascript implementation on the server side if you want to do things like server side caching, and supporting Agents(browsers, bots etc) that do not use javascript on the client side.
Just json files. Just javascript. Just the DOM.
You are (currently) using the wrong templating system.
Front end developers know how to use this technology. They know this technology very well, so will be way productive.
No weird new template language to learn and install on every single project.
No dependency on a rapidly changing server side backend... or database, or 3rd party API required.
No taking the html, and turning it into [$%%WEIRD TEMPLATE LANG%%$$] step. Instead you can use javascript, json and the DOM.
Being able to use the templating system either via the browser, or via the server side means there is no dependency between the front end and the back end. Front end developers just need an example json file to work from. Then the back end developer just needs to create the json file.
It does mean you are dependent on a DOM+javascript implementation on the server side if you want to do things like server side caching, and supporting Agents(browsers, bots etc) that do not use javascript on the client side.
Just json files. Just javascript. Just the DOM.
You are (currently) using the wrong templating system.
Comments
Besides, that would require yet another HTTP request to the server. More latency, more user CPU usage.
Thirdly, server-side processing templates can be cached. Client-side templates can't.
If you are wanting to use a templating system that doesn't introduce extra tags just use ZPT e.g.:
http://www.slideshare.net/hammertoe/an-introduction-to-zope-page-templates-and-their-use-outside-of-zope
http://www.netsight.co.uk/blog/2010/2/4/zope-page-templates-in-google-app-engine
-Matt
I'm presuming you have some cunning plan to run javascript on the server to generate html resources - please share!
I like ZPT so much that I use an XSLT version of it (lxml converts ZPT to XSLT that can be used server-side or client-side).
I also wrote a javascript version of ZPT as well. Both are great.
Not sure what this post is about though without some examples..
Cheers,
Templating systems do suck though, thats why I've been working on XDV which lets you define a simple rules file for merging your content into a plain html theme.
@bkc,
Can you point me at the ZPT -> XSLT conversion, sounds really interesting.
I could see this working and there is obviously some value in it. The disconnect between templates, snippets and ajax handlers disappears into a unified interface, which is a pretty powerful idea. No longer would you have to consider hints in the request as to what to process and return (html, json, html snippet).
The downside in my mind is that at some point you would have to come up with some tools to make the whole process simpler. jQuery would be a nice start but that would require the Javascript processor on your server have the necessary DOM aspects.
I'd be curious as well what sorts of additions or framework would be needed. For example, most template systems have a means of including or inheriting other templates. This makes it much easier to make your templates modular. It seems like there would be instances where you'd want similar syntax. Of course, that might simply be an anchor tag with a specific "includes" class.
In any case, it is an interesting idea. I'd like to see if anyone has tried it outside of the server side javascript realm.
I too would like to see some examples (even if they're non-working pseudocode) of what your idea is.
I also would think that caching and searchability are key issues, but people developing GWT applications don't seem to worry much about this, so maybe it's a non-issue?
Although I love ZPT (especially because of James Clark's nxml-mode for emacs), traditional templating does create a middle-man between the html coders and the backend. Personally I know zero-design, a bit of html/css/js and alot about templating and backend. Most of my time is spent templating but really I'd rather spend most of the time on the backend :)
The problem I see with the json/dom approach though is similar to issues I've come across with push templating libraries in general. It tends to separate the data from the templating structure so much it feels very disconnected and fragile.
I'm with elarson, seems like some kind of framework would need to be built to eliminate the tediousness of raw dom manipulation. Would that eliminate the middle-man template master or just create a new breed?
lawrence: the criticism about AJAX pages being invisible to search engines is valid, but it may not be true forever. Google has its own javascript engine; what is keeping them from having their spiders do jscript rendering?
Sorry for the poor confusing writing in the blog post.
One way of implementing this would be to import 'server side' js first before client side js.
Then it's just a normal dynamic HTML page. Get your json object/s from a URL, or just included in the page as javascript, and modify the page.
At this point, you can save the html and send it out to the client. Or you can start running the other client side JS.
It can act either as completely client side templating, or completely server side templating.
You could do includes by reading other html, and then finding the parts you want in there, and inserting it. Using an include class of some sort would work well I think as you suggest.
However, different front end developers would use different tool kits. eg, one may use jquery, another GWT, another YUI.
I haven't used this technique for a whole project, but it has worked well for parts of it. The server side programmers just produce the json, and the front end ones just produce the html+js. Neither of them have to even see the other persons work - except for the sample json.
No need to translate the html into a template, and no need to have the server side code even finished! Just save a .json file, and the front end programmer can work. They don't need to set up apache, download 32 libraries, run a server on a different OS, get a database set up... and file bugs with the server people, and the admin people. All those problems are removed.
No need to train up the front end programmer in the platform, or the templating language of choice either. Also the back end coders do not have to edit something they don't know that much about (html/css/js), so the quality remains higher.
cu.
Example can be a Slashdot page. If the client has to pick up a template HTML and then fill in the hundreds of comments from JSON files that will take a non-trivial amount of time. Slashdot bakes a static page once and then serves it to multiple clients.
Besides, if you keep the same HTML file and have AJAX requests to update the data when the user clicks something, you'll have to do all those "URL tricks" to ensure the user gets to the right page if he e.g. bookmarks it or send the URL to a friend.
Client-side templating is OK for RIAs, where it's already used. But not for most web sites.
Now, server-side is a different matter. Yes, it's interesting, and you'd end up with a machine-parsable view for free.
But you still need to generate the HTML that XDV eats, and that is still best done with a templating system of some sort. Personally, I like "templess", but never have a chance to use it, so I'm stuck with ZPT.
I was thinking that you could run a headless webkit on the server to static-ify AJAX applications for non-JS clients (spiders in particular).