@SH
It's important to think about the process that's going on here. The
language you're using to describe the problem is a little confused and
it might help a lot to get a bird's eye view of what you're doing. In
the simplest scenario the controller instance is a very short-lived
object that springs to life only to answer a question posed by the
user. It's job is to gather enough information to answer the question
and reply in a way that the user understands... and may eventually ask
another question. In a sense it's part of a conversation with the
user. In this regard you are not 'passing local variables to another
controller', you are answering a user request and the user is making a
completely new request to some other controller. It's an important
distinction to make because it will help keep you from thinking in
terms of sending messages to another controller; controllers respond
to browsers.
Specifically here the main question to ask is whether the Descriptions
will *always* be attached to Items. If so then you can do a few
things that will really simplify your coding.
1. Modify your routes.rb file, nesting the descriptions resource
inside the items resource:
map.resources :items do |item|
item.resources :descriptions
end
By doing this you explicitly state to the Routing system that
descriptions belong to items. The bonus is that you get named routes
to help you with your main issue.
2. Use the named route in your link_to
<%= link_to 'Describe', new_item_description_path(@item) %>
This will build a url for you that will look something like /items/15/
descriptions/new. The advantage is that the route is created by the
Routing system so you can't miss. Better still, the intention of the
code is much clearer. (As a side note, I am assuming that you got
the :locals reference by reading some about partials... it's not
necessary here).
3. Code the expectation for an Item into the Description model.
The main argument for the nested route (#1) is that the nested item
only makes sense in the context of it's parent. In this situation,
the Description is only meaningful with its Item. You can/should make
that explicit in your controller. When it responds to the request to
make a new Description for an Item it can say so:
class DescriptionsController < ApplicationController
...
def new
@item = Item.find params[:item_id] # Note: item_id is created by
the named route
@description = @item.descriptions.build
end
def create
@item = Item.find params[:item_id]
@description = @item.descriptions.build params[:description]
respond_to do |format|
if @description.save
...
end
end
end
end
4. Also let your new.html.erb take advantage of the named route
<% form_for :item, :url=>item_descriptions_path, :method=>:post do |f|
%>
...
<% end %>
Here you're going to post a new entry into the Item.descriptions
collection (you can clean this up further if it's a singular
resource). The create method (above) will receive the parameters. As
with #new, it already understands that it's scoped to an Item and the
named route has made sure that you got the item_id.
@item.descriptions.build params[:description] will build a new
Description object using the values that the user keyed and
automatically pop the scoping item_id in as well (note -- item_id was
not available to the user!).
