据我有限的见识，RESTful 是没有批量创建这个说法的，创建和更新都是基于单个的资源。

在实践上来说这种做法也需要特别的处理，比如说批量插入 10 个，其中一个失败，那么返回什么信息，其余成功的怎么处理，要不要回滚等等。

我建议如果可能，不要做批量的插入，而是做单个资源的更新。假设 user has many books, 你可以 PATCH user, 然后用 accept_nested_attributes_for 更新。如果 user 不适合的话，你甚至还可以创建一个简单的 upload model, 对应每一次的操作。如果都不适合，还是多发些请求，一个个地更新比较好。

我曾经用过 Amazon S3 的 web 管理界面，批量删除和更改都是一个个的请求发的，看起来又慢又笨，但其实他们还是有绝对的理由这么做的。

你在自己的 transaction 里面写个ChildClass.where(id: new_arr).delete_all不就完了么。

刚毕业那是多好的时光。不要纠结少赚一个月几千块的工资收入，先啃老一年，把刀磨快了再上战场。上了战场就以消耗为主了，顶不住消耗就更没有时间磨刀了。

hover 移出左边时不要做任何事情。监听右边的移出就可以了。另外右边因为是动态的，所以不能直接绑定事件到右边，要使用高些级别的 element。比如$(document).on('mouseleave', '.menu-sub', function(){ /*同时移除右边和左边的current状态*/}

自己动手是有点复杂。或者看看有没有什么内部滚动的组件把图表包起来，不要直接动图。

ionic 是把所有的 touch events 都统管起来，然后区分什么是 click, 什么是 scroll, scroll 的力度，还有其他各种手势。

没有遇到过具体的这种情况，但目测是这个原因。我想 CSS 设置可能不会起作用，可能需要自己写一个 directive, 使用 jqlite, 自己监听 touch 事件，然后需要滚动的就滚动，和这个无关的就一概向上抛出去还给 ionic。或者搜搜有没有现成的插件或者片段。

卖货的才用 99 结尾啦 显示价格低。买货的肯定要多出个零头。。。

其实不需要找理由，web 和原生的体验完全是两回事。我们同款 app, ios 的做原生，android 的以 ionic 为基础，体验完全不一样。

localForage, webWorker 这些都不是 killer, 我们都用上了，当然有效果，但谈不上靠这个媲美原生的。Object.observe 更谈不上了，只是一个新 API 而已，ES5 靠 polyfill 也能实现。Angular 的内在实现本来就和这个差不多，React 更是超越其上。

而且 Javascript 的开发也不能说是更容易，你要是照着框架来做千篇一律的东西当然不难，但要想玩出花，不费硬功夫是不行的。

我觉得不需要找理由，不需要偷懒。你要是公司，如果有人有预算有追求，肯定上原生。如果是开发者，要勇敢跳出自己的 comfortable zone, 什么好就学什么，用什么。

你这个不是常规做法。为什么不直接用 require.

有 zero downtime 的实践，操作起来也要注意很多东西，但主要目的还是为了用户使用不受影响，不是以调试代码为目的的。

他自去当他的内行，你自去经营改进你的网站。他继续看笑话，你继续出成绩。

你是去学知识的，又不是去看牛的，人家拉不拉得到赞助和你要不要学知识有什么关系。

@xhj6 这个当然是有区别的。用一套系统依赖只在一处，用两套依赖在两处。另外你如果用 webpack, browserify 的话 npm 是首选，因为很多 bower 包是不匹配 CommonJS 的。

如果你需要再次更新本模型，那么你不应该使用 after_save 的回调。after_save 的常见场景是通知其他部分，比如通知其他 model 更新，更新缓存，发送 queue 等等。

本模型的两个更新动作可以包裹在一个 transaction 里面执行。你这个例子里面第一个动作还包含了 IO，因此除了 ActiveRecord 的常规错误之外你还可以监视 IO 错误来直接 Rollback。

客户端带个约好的 Header 表明自己的身份就可以了，不需要下命令说“我要验证！”是否要验证或其他逻辑的区别交给后端操心。另外就算说要验证也没有什么不安全的。

这个不复杂，你的逻辑你自己爱怎么处理就怎么处理，多好。

当开始数 10 的时候，楼主心跳开始加速

你这里的 scaleStepWidth: 1000 应该是动态的啊，试试设置一个函数根据数据大小实时调整。

@yan32768 你太多猜想了，这些都是很简单的东西，哪里有那么纠结。动手先做出来再说。代码整理和优化可以等做好了再优化。

如果一个页面里面有多个 modal, html 里面带一个通用的就可以了，用 Javascript 动态填充内容。这个不是服务器端的活。

@darkbaby123 明白了，谢谢！这个挺好，看着很简便。现在用着 rvm, 下次要折腾就试试它了

请教 chruby 的 gems 也是按版本分开放的么？

可以看出楼主的选择基本没有经过验证，很多都还是在道听途说＋想象的阶段。个人建议是不妨改标题为试验 xxx，或者是先试试，比较成熟之后再分享。

首先你得把 markup 写对，不然问题一个接一个。按 Bootstrap 定义 modal-body 是不包裹 modal-footer 的，你这里包裹了，还把 form 混在一起。

写个干净的 html, 把 form 放到 modal-body 里面，可以不要 button。然后监听 modal primary button 的点击事件，安排 form submit 就可以了。

@jimxl 你把服务呼叫放在外面那缓存还有什么意义。

@martin91 不急一时的，慢工出细活。

非常棒！:plus1:

楼主能否贴个 PR 链接？我们也有类似的代码，只是还没有曝出问题

@hxh1246996371 现实的另一面是，为了匹配低端的浏览器，程序员需要花大量的时间和精力在低价值和即将失效的事情上面。高层为了这些用户，需要付出的成本是程序员的乐趣和工作积极性，大量的开发时间和可能需要放弃的先进功能。就看怎么算帐了。