标签：http os io 使用 java ar for 数据 问题
服务器端生成的 JavaScript 响应 英文原文：Server-generated JavaScript Responses Basecamp中的大多数Ajax操作都是在处理服务器生成的JavaScript响应（SJR）。它的工作原理是这样的： 表单通过一种XMLHttpRequest驱动的形式提交。 服务器创建或更新模型对象。 服务器生成包含了针对该模型对象的更新了的HTML模板的一个JavaScript响应。 客户来评估处理由服务器返回的JavaScript，然后会更新DOM。 这种简单的模式有一些重要的优势。 优点#1：重用模版而不影响性能 无论是第一次渲染和随后的模版更新,你都可以重用模版.如果使用Rails,有一部分技术像邮件/信息用于这两种情况。 如果你只返回JSON格式的信息，你得用你的模版将展示这些信息两次(一次是服务器端的第一次回应，一次是客户端随后的更新)—除非你做一个单一面页的JavaScript app,这个app的第一次回应是用JSON/客户端生成方式。 后面那种方式会很慢，因为要等整个的Javascript库load完并在客户端生成好模版你才能看到效果(这是Twitter早期所用的方式，但随后被背弃)。但至少在某些情况下这是一个合理的选择而且不需要多个模版。 优势 #2: 客户端需要更少的计算性能 虽然嵌入HTML模板的JavaScript可能造成响应数据量比JSON格式的响应要多（尽管用gzip压缩后几乎可以忽略），但是这不需要客户端去做很多的运算来更新页面。 这意味着，从端到端的观点出发，处理 JavaScript+HTML的响应数据的速度，应该比处理带有客户端模板性质的JSON数据要快，至于快多少，取决于客户端模板的复杂程度，以及客户端计算性能。而且这个速度应该是二倍关系，因为，服务器生成的模板可以通过缓存在多个用户之间共享（详见 Russian Doll缓存）。 优势 #3: 容易跟踪执行流 使用SJR会让跟踪执行流变得非常容易。请求的机制是标准化的，是会带有辅助逻辑“likeform_for @post, remote: true”. 当然没有必要对于每个动作都带上辅助逻辑。 接着控制器会以渲染完整视图的方式来渲染响应中的部分视图，其中的目标只能是JavaScript 而不是完全的HTML 完整示例 0)首先使用消息模板标签：http os io 使用 java ar for 数据 问题
原文地址：http://www.cnblogs.com/chenzhenzhen/p/3953011.html
