Comments on: Simple ‘on-server’ mobile AJAX in Django

By: Mike

Mike — Tue, 09 Nov 2010 20:08:58 +0000

I found your blog on bing and will bookmark it now. Keep up the nice work.

By: Steve

Steve — Tue, 21 Jul 2009 09:22:44 +0000

That’s pretty nifty.

It’s things like this that make me love Django

I was thinking of extending the built in Template object and render_to_response function to decide which template to use (mobile, json, xml, desktop etc.), meaning you could take that little bit of code out of your views.

By: James

James — Sun, 19 Jul 2009 05:14:26 +0000

Hi Steve,

w.r.t. to mobilization, I use middleware that decides which page to display (based on this algorithm) and then pops its decision into the request object.

A context processor then puts the master mobile-or-desktop template name into a universal context variable called page_template, and then my page.html template (which all pages derive from) is literally just:

{%extends page_template%}

(NB: page_template is a variable, not a literal – that’s the trick)

I then just need something like page.mobile.html and page.desktop.html with the appropriate skeleton of the two types of page (but with mostly the same key blocks), that this extends tag will refer to.

… in other words I am able to dictate the top-level look from the incoming request without doing anything too unnatural with respect to templates and settings

I need to write this up I guess.

By: Steve Anderson

Steve Anderson — Thu, 16 Jul 2009 22:04:38 +0000

I’ve just realized that you actually do this in quite a nice way, by building up the string in your view and calling render on the correct template. Makes sense. I must have misread.

Even so, it’s handy to know about changing settings on the fly being dangerous.

By: Steve Anderson

Steve Anderson — Thu, 16 Jul 2009 22:01:45 +0000

One thing to be wary of with Django, is that switching templates in real time based on the request is NOT THREAD SAFE, and you must be extremely careful to reset any settings that you modify at runtime. The Django docs (http://docs.djangoproject.com/en/dev/topics/settings/#altering-settings-at-runtime) display a very mysterious message simply telling us never to do anything of the sort, but don’t really explain why!

This talk by Simon Willison sums up a few of the annoying things about settings.py, one of which being that changing settings at runtime is not thread safe – http://simonwillison.net/2009/talks/eurodjangocon-heresies/.

I unfortunately learned this when trying to write my own mobilization middleware for Django (http://www.djangosnippets.org/snippets/1437/). I’m still looking for a decent way to do dynamic template switching with Django, but the globalness of settings.py makes this a bit difficult.

Simon has suggested some improvements (http://simonwillison.net/2009/May/19/djng/), but of course this involves some significant reworking of the Django core.

I think we definitely need to look into a better way of doing this for Django, as it is a growing need of a lot of apps built in the framework. It’d be good to hear your thoughts…

By: Paul

Paul — Wed, 17 Jun 2009 13:19:17 +0000

Neat. I think this approach has applications beyond the mobile/XHR context, too, though they may not be quite as interesting. Could eliminate the need for custom inclusion tags in some cases.

Specifying output format via filename extension is simple and REST-y. Takes me back to the first piece of software I saw that did that dynamically and well: Blosxom.

(Found this via the Djangosnippets Twitter feed, BTW.)

By: Bryan Rieger

Bryan Rieger — Wed, 17 Jun 2009 11:59:48 +0000

Very nice idea indeed. I the fact that you’re still able to support both clients with and without Javascript using this approach.

BTW – nice note on http://ivyroot.com