我正在开发一个标准的 Rails 应用程序，到目前为止我还没有使用任何 AJAX，只是使用了很好的 HTML。我的计划是迭代地添加“远程”链接和所有此类内容以及对 JS 响应的支持，因为我知道生成 JS 服务器端是非常非常邪恶的，但我发现它也非常方便，简单，快速并且它使应用程序足够敏捷，并且 i18n 开箱即用。
使用纯 JSON 方法会更轻，但需要大量客户端编码。
现在想象一下，在此应用程序中，用户有一个邮箱，并且由于他们无需重新加载页面就能够执行大部分甚至所有操作，因此邮箱计数器永远不会改变，除非他们手动刷新页面。
那么，问题来了：处理这个问题的最佳方法是什么？
我考虑过使用 Ember（用于数据绑定），并通过 ruby 的某种把手实现与 Rails 共享视图。这将是非常棒的，但对于开发人员（我）来说不是很透明。虽然我猜我只需要编写 ember 将使用的车把视图，但其余的仍然可以按原来的格式编写，不是吗？
另一种选择可能是使用某种事件系统（可能是 EventSource？），然后使用方便的 JS 视图方法，并监听这些事件。我想这些应该是 JSON 对象，并且客户端必须进行编码才能处理它们。这看起来有点麻烦，我需要一个heroku（faye？）的解决方案，这是我的应用程序的托管位置。有什么提示吗？
我认为 ember 方法是更强大的方法，但似乎也相当复杂，而且我不想在服务器和客户端方面重复自己。
EDIT:
我见过this http://layervault.tumblr.com/post/30932219739/rails-in-realtime，这或多或少是选项#2。
使用 JavaScript 框架的优点之一是可以将整个应用程序连接并压缩为一个 JavaScript 文件。如果现代浏览器积极缓存 JavaScript，浏览器将不再需要在初始页面加载后请求这些资源。
使用 JavaScript 框架的另一个优点是它要求您成为自己的 API 的使用者。如果移动应用程序或第三方有可能访问它，那么充实应用程序的 API 供您自己使用可能会减少将来的工作量。
如果您不需要应用程序使用等效的 HTML 响应来响应每个请求，我认为使用 JavaScript 框架是一个令人信服的案例。
如果您的应用程序需要使用等效的 HTML 模板来响应每个请求，那么许多好处可能会丧失。 Ember 核心相对强烈地反对支持这种渐进增强的方式。考虑到以这种方式使用 JavaScript 框架的工具相对不稳定且不成熟，我可能倾向于使用选项 2 来完成此任务。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
