如何升级:update=>'div_id'从 Rails 2 到 Rails 3 的 remote_form_for 选项?
我不知道如何将此代码从 Rails 2 升级到 Rails 3:
<% remote_form_for(item, :update => 'div_id') do |f| %>
...
我尝试了以下操作:
<%= form_for :item, :remote => true, :url => { :controller => "items", :action => "create" }, :update => 'div_id' do |f| %>
...
它创建了新项目,但在
标签。 Rails 3 似乎不再支持远程 更新内容失败 “div_id”>form_for
的“:update
”选项。有什么建议吗?
I can't figure out how to upgrade this code from Rails 2 to Rails 3:
<% remote_form_for(item, :update => 'div_id') do |f| %>
...
I tried this:
<%= form_for :item, :remote => true, :url => { :controller => "items", :action => "create" }, :update => 'div_id' do |f| %>
...
It creates the new item but it fails in updating the content within <div id="div_id"></div>
tags. It seems Rails 3 no longer supports the ":update
" option for a remote form_for
. Any suggestion?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以使用 RJS,但它也已被弃用(并且有充分的理由)。在 Rails 3+ 中处理此问题的简化最佳实践方法如下(假设 jQuery):
jquery-ujs(又名 jquery-rails、又名 Rails-)调用
ajax:success
挂钩ujs) 远程链接/表单处理程序。 亲自看看。 有还有许多其他回调/挂钩可供您使用。如果您想让它更加灵活,您可以使用live
而不是bind
,并绑定到一个指示输出去向的类(例如“侧边栏”)和那么所有带有sidebar
类的远程链接/表单都会将其 HTML 响应发送到div#sidebar
。You could use RJS, but that's being deprecated too (and for good reason). The simplified, best-practices way to handle this in Rails 3+ is as follows (assuming jQuery):
The
ajax:success
hook gets called by the jquery-ujs (aka jquery-rails, aka rails-ujs) remote link/form handler. See for yourself. There are lots of other callbacks/hooks available for you to use, too. If you wanted to make this even more flexible, you could uselive
instead ofbind
, and bind to a class that dictates where the ouput goes (e.g. "sidebar") and then all remote links/forms with thesidebar
class would have their HTML response go todiv#sidebar
.最直接的方法是编写一个 javascript 视图模板,例如
create.js.erb
,它看起来像这样:(当然,取决于您的设置,我假设
@item
变量和关联的_item
部分)编辑:
科里沃德是对的。这是 RJS 方式,更像是老式的 Rails 2.x“Rails 方式”。它可能更熟悉,但有问题。实际上,您的具体情况就是其中之一,通常您可能会绑定到 HTML 元素以使用记录的
id
(例如 div #item_1)进行更新,并在create
中如果事先没有可用的id
,事情就会变得复杂。通过客户端 JS 绑定消除了这个问题。 RJS 在某种真空中工作,对客户端 HTML 的状态做出假设并且无法访问它。
The most straightforward way to do this would be to write a javascript view template, e.g.
create.js.erb
which would look something like this:(depending on your setup, of course, I'm assuming an
@item
variable and an associated_item
partial)Edit:
coreyward is right. This is the RJS way which is more of the old fashioned Rails 2.x "Rails way". It's probably more familiar, but has issues. Your specific case is one of them, actually, as typically you might bind to an HTML element to update using the record's
id
(e.g. div #item_1), and in thecreate
case there is noid
available beforehand, complicating matters.Binding via clientside JS eliminates this issue. RJS works in something of a vacuum, making assumptions about the state of the client's HTML and having no access to it.
我知道这个问题很老了,但是当我迁移到 Rails 3 时,我发现了一个很好的方法来做到这一点,所以我想我会把它发布在这里,以防其他人有类似的解决方案。
在layouts/update_page.js.erb中,我放置了这个文件:
这主要用于使用远程的搜索,因此在控制器的索引操作中,我刚刚添加了以下代码。
由于正在使用远程,它总是会首先尝试使用 javascript,因此它将从上面渲染 update_page.js.erb 文件。对于我们来说,我们几乎总是在索引页面上使用 div#list_div,因此我们默认更新它,但是如果您需要更新不同的内容,您可以传入 @update_div_id,如果您需要渲染不同的页面,你可以传入@partial_div。
澄清一下,对于很多事情,使用回调可能是更好的做法,但我发现当我们必须迁移近 100 个这样的调用时,这是一种更简单的方法。
I know the question is old but I when migrating to Rails 3 I found a pretty good way of doing this, so I thought I would post it here in case anyone else is in a similar solution.
In layouts/update_page.js.erb I put this file:
This is mainly used for searches that use remote, so in the index action in the controller, I just added the following code.
Since remote is being used, it will always try to use javascript first, so it will render the update_page.js.erb file from above. For us, we almost always use the div#list_div on our index pages, so we update that by the default, however if you need to update something different, you can pass in @update_div_id, and if you need to render a different page, you can pass in @partial_div.
To clarify, for a lot of things, it is probably better practice to use the callbacks, but I found this to be a much easier way, when we had to migrate over nearly 100 of these calls.