Cappuccino、Django、AJAX，并将它们组合在一起 - 回顾我的架构！

我正在尝试了解卡布奇诺。我希望我的 StackOverview 同行审查下面的架构，看看它是否有意义 - 目的是利用 Django 和 Cappuccino 的独特优势，而无需在技术重叠的地方加倍......

当 Web 浏览器请求“友好”URL（例如 /、/articles 等）时：

• DJango 的 urls.py 将其与 看法。
• 只看风景，而不是做事 DJangos 填表的典型工作 带有当地人字典的模板，
  返回在中使用的小“存根”HTML 直接卡布奇诺应用程序。
• 客户端收到 Cappuccino HTML
• 客户端请求 Objective J JS 存根 HTML 中提到的 URL
• 最终用户应用程序被执行并且 显示在浏览器中

浏览器现在有一个可以运行的应用程序。当用户做了某事时 从服务器请求一些东西：

• 浏览器向 URL 发送 XMLHTTPRequest。
• Django 的 URLs.py 将其与 看法。
• 该视图确实有效，可能与数据库模型交互。但 Django 不返回模板，而是返回一些 JSON。
• 客户端收到 JSON，并且 做它需要做的任何事情。

这有道理吗？我们仍然受益于友好的 URL，以及为我们创建代码模型的数据库。然而，我们不是使用模板，而是提供 Cappuccino 存根页面和 JSON 响应，以便为用户提供更像真实应用程序而不是 HTML 模板引擎的东西。

也许有更好的做事方式吗？其他 Pythonista 使用什么？感谢您的反馈意见。

对于低流量站点，使用 Django 的路由层就可以了，但如果您计划获得大量流量，则可以考虑让代理 Web 服务器处理存根。

至于其余的，它是有效的，TurboGears 社区已经这样做了很多年（我是 TG 提交者，所以这就是我通常使用的）。将字典返回到模板的 TG 架构使这变得微不足道，因为您只需将“json”设置为模板引擎。

在 Django 中做同样的事情并不复杂。只需使用序列化 http://docs.djangoproject.com/en/dev/topics/serialization/将结果写入响应而不是使用模板调用的工具。

请注意，当您构建这样的架构时，如果将所有应用程序逻辑保留在一个位置，管理起来会容易得多。将一些应用程序逻辑放在 Django 中，另一些放在浏览器中会导致事情很快变得混乱。如果您将服务器视为哑持久层（验证/身份验证/授权除外），那么生活会更轻松。

FWIW，如果您对较重的非渐进式增强框架感兴趣，我发现 Sproutcore 比 Cappuccino 更容易使用。