This would move the relevant contact_id to the notes controller and
you can get it using params[:contact_id] in the create method like so
@note = Note.new
@note['contact_id'] = params[:contact_id]
Since you would have a contact_id field defined in the Note model, it
would then make sense to define a hidden field in your notes-
If you choose to use RESTful routes, you could also nest the Notes
resources within the Contact resources. In that way, the url will
contain the id for the contacts and it will be available by
implication in the notes_path that you'd use for your forms.
Sorry to hijack this, but I have a similar question that revolves
around a RESTful design:
I am only working with one class - Person. But each person can have
one parent. parent_id is used to link them to another person (each
person only has one parent).
This RESTful style link
<%= link_to "Create New Person", new_page_path %>
will take me to the form to create a new person. But that person will
not have a parent_id set (similar to Nik's origninal problem)
I can pass the value to the params hash using this:
<%= link_to "Create New Person", new_page_path(:parent_id =>
@person.id) %>
But now I run into the problem that in my RESTful controller, there is
a new action for the form which then passes to the create action (to
actually create the object). How would I keep the reference to
params[:person_id] so that it could be passed on to the create action?
I like the idea that Nik has of using one action for edit and new. Is
it a necessity of RESTful design to have the standard 7 actions
(index, show, new, create, edit, update, destroy) separate or would it
be considered okay (DRY even) to combine them (or omit them in the
case of new, where a postback could be used instead of passing from
the new action to the create action)?