This comment has been minimized.

@Gimi Rails is designed to be able to route most requests without looking at the payload. Routers are expected to be fast, so if a request is slow the developer will at least know which action was called when the slowness was encountered.

@Gimi Rails is designed to be able to route most requests without looking at the payload. Routers are expected to be fast, so if a request is slow the developer will at least know which action was called when the slowness was encountered.

This comment has been minimized.

@benatkin I understand. So, I just think that /posts/many may be unnecessary? No matter how many resources are going to be created, just POST them all to /post is enough. Sometime, you even have no idea how many resources will be created, say I have a form for users to create child groups for a group, and users can add child groups dynamically, which means you may create one or ten groups in the action. create just feels a little bit different from the other default actions to me.

@benatkin I understand. So, I just think that /posts/many may be unnecessary? No matter how many resources are going to be created, just POST them all to /post is enough. Sometime, you even have no idea how many resources will be created, say I have a form for users to create child groups for a group, and users can add child groups dynamically, which means you may create one or ten groups in the action. create just feels a little bit different from the other default actions to me.

This comment has been minimized.

Is it just me, or does anybody else get the feeling that this could lead to some very unDRY code? It seems that show_many and index will typically wind up being copies of each other except that they pull from different parameters. Any any sort of logic added to a create, update or destroy will have to be duplicated in it's _many counterpart. It seems like the code will typically be identical across single or bulk actions, only their responses seem like they need to be handled differently. And even then how would a failed validation on a create or update be handled? Would it render a new_many or edit_many? I'm still fairly new to Rails so maybe I'm not understanding how exactly this will be implemented.

Is it just me, or does anybody else get the feeling that this could lead to some very unDRY code? It seems that show_many and index will typically wind up being copies of each other except that they pull from different parameters. Any any sort of logic added to a create, update or destroy will have to be duplicated in it's _many counterpart. It seems like the code will typically be identical across single or bulk actions, only their responses seem like they need to be handled differently. And even then how would a failed validation on a create or update be handled? Would it render a new_many or edit_many? I'm still fairly new to Rails so maybe I'm not understanding how exactly this will be implemented.

This comment has been minimized.

@sinsiliux I just noticed where(:id => params[:ids]) != where(:id => nil) - I think this was not the case in Rails 2.3.x (old finders). Anyway, my basic point was that for me params[:ids] should be same as params[:id] to avoid singular vs. plural getting in the way.

@sinsiliux I just noticed where(:id => params[:ids]) != where(:id => nil) - I think this was not the case in Rails 2.3.x (old finders). Anyway, my basic point was that for me params[:ids] should be same as params[:id] to avoid singular vs. plural getting in the way.

Is it surprising that params[:id] is always the first of many IDs? Aside from the obvious case of overwriting an explicitly passed :ids parameter, when would this cause problems? Anyhow, here's how I make use of it in a trivial #update example.

def update
# Gracefully ignores invalid IDs
@posts = Post.where(:id => params[:ids])
@posts.each do |post|
# Enforce policy if desired on each post...
post.update_attributes(params[:posts][post.id.to_s])
end
# What results are returned considering some updates may have failed?
end

I've created a little Rails app with some different examples and tests.

Is it surprising that params[:id] is always the first of many IDs? Aside from the obvious case of overwriting an explicitly passed :ids parameter, when would this cause problems? Anyhow, here's how I make use of it in a trivial #update example.

def update
# Gracefully ignores invalid IDs
@posts = Post.where(:id => params[:ids])
@posts.each do |post|
# Enforce policy if desired on each post...
post.update_attributes(params[:posts][post.id.to_s])
end
# What results are returned considering some updates may have failed?
end

I've created a little Rails app with some different examples and tests.