Cappuccino, Django, AJAX, and fitting it all toget

Question

I'm trying to get my head around Cappuccino. I'd like my StackOverview peers to review the architecture below and see if it makes sense - the aim is to utilize the unique benefits of Django and Cappuccino without doubling up where the technologies overlap...

When the web browser requests a 'friendly' URL (eg, /, /articles, etc):

• DJango's urls.py matches this to a view.
• The view, rather than doing DJangos typical work of filling in a template with the locals dict,
  returns the small 'stub' HTML used in a Cappuccino app directly.
• The client receives the Cappuccino HTML
• The client requests the Objective J JS URLs mentioned in the stub HTML
• The end-user app is executed and displayed in the browser

The browser now has a working app. When the user does something that requests something from the server:

• The browser sends an XMLHTTPRequest to a URL.
• Django's URLs.py matches this to a view.
• The view does it work, perhaps interacting with the DB model. But instead of returning a template, Django returns some JSON.
• The client recieves the JSON, and does whatever it needs to do.

Does this make sense? We still have the benefit of friendly URLs, and the database being created for us to model our code. However rather than using templates, we're providing Cappuccino stub pages and JSON responses, in order to give users something more like a real app and less like an HTML templating engine.

Is there perhaps a better way of doing things? What do other Pythonistas use? Thanks for your feedback.

Answer 1

For a low traffic site, using Django's routing layer would be fine, but if you plan on getting a significant amount of traffic, you might consider having your proxying webserver handle the stubs.

As for the rest, it works and the TurboGears community has been doing it for years (I was a TG committer so that's what I normally use). The TG architecture of returning a dictionary to a template makes this trivial since you just set 'json' as your template engine.

Doing the same thing in Django isn't much more complicated. Just use the serialization tools to write the result to the response rather than using the templating calls.

Note that when you do an architecture like this, it's considerably easier to manage if you keep all the application logic in one place. Putting some app logic in Django and some in the browser causes things to start getting messy fairly quickly. If you treat your server as a dumb persistence layer (with the exception of validation/authentication/authorization), life is easier.

FWIW, I find Sproutcore to be easier to work with than Cappuccino if you're interested in heavier non-progressive enhancement frameworks.