views:

63

answers:

3

Lets say we have a Company model, that has many Employees And has many Projects

If we want to show the projects, we'll go to
"/company/1/projects/index"

If we want to edit 1 project, we'll go to
"/company/1/projects/1/edit"

What if we want to edit all the projects at once on the same webpage?
We can go to "/company/1/edit" and put a nested forms for all the projects

But what if we need a different webpage to edit all the employees at once too?
We can't use "/company/1/edit" again..

Right now we do "/company/1/projects/multiedit", "/company/1/projects/multupdate"- but as you can see, it's not rest.

How can we model this restfully?

A: 

API:
http://apidock.com/rails/ActiveRecord/NestedAttributes/ClassMethods/accepts_nested_attributes_for

Check Rayan Bates Railscasts:
http://railscasts.com/episodes/197-nested-model-form-part-1
http://railscasts.com/episodes/197-nested-model-form-part-2

fl00r
Nested attributes can be useful, but I'm struggling to understand how they help with defining resources and actions. Am I missing something here? I must admit I haven't watched the screencasts, but I had a look at an example of using nested attributes [here](http://weblog.rubyonrails.org/2009/1/26/nested-model-forms).
Alex - Aotea Studios
Nested attributes can't help you in this way. But you can use variables `/company/1/edit?what=employees` or '/company/1/edit?what=projects` and render form reffered to `what` variable
fl00r
You can, but that doesn't seem very RESTful to me. Wouldn't `/company/1/edit_employees` and `/company/1/edit_projects` be nicer and more straightforward to implement (just a couple of routes and actions, no conditional code to check parameter value)?
Alex - Aotea Studios
`/company/1/employees/edit` and `/company/1/projects/edit` but only if you don't need member action for edit (project/1/edit) else `/company/1/edit_employees` is ok
fl00r
Sorry if I didnt explain it right- I know how to implement nested forms, the question was about the controllers/urls/resource point of view, not the actual implementation.
amikazmi
A: 

I think the way you are doing it now is pretty good actually. Inventing artificial resources just to fit in with the basic REST URL scheme doesn't seem right to me. Besides, Rails has collection and member routes precisely for the purpose of adding extra actions, so what you're doing is in line with the Rails philosophy.

For me defining resources and actions is similar to designing classes. Sometimes you add a few methods and realise that the design would be better if you divided the class into two, but other times the class just needs to have all those methods.

Do you have a bona fide resource other than companies and projects that should handle multiedit and multiupdate? I think not. But then again, just as with classes, sometimes it's a matter of opinion.

Alex - Aotea Studios
I (also) thought this way was good enough, but most of the gems/plugins works best with rest conventions, and we have to work around them to work with this "multiupdate" actions. Every resource that is tightly coupled to the "parent" resource is a good example, but I guess it's a matter of opinion what gives a resource the "right" to stand alone.
amikazmi
+1  A: 
Chris McCauley
The reason to be RESTFul is to play nice with other plugins. The reason to update the "child" resources on the same time is that it's all or nothing update (transaction like?)- if we'll update them one by one they'll break our model invariant.. if I understand correctly, batching all the POSTs wont help in this situation?
amikazmi