This is easy, I know, but looking over the wiki and doing some Google
searches turns up nothing. I want to use a related table¹s controller to
enter data for its model, then on success, redirect to the parent table¹s
controller. An example:
I have a Thang and each Thang has_one Assumption. When I create a Thang (in
my controller), I create an Assumption with default values (from the
database) and present a nice ³modify adjustments² link on the Thang list
page.
The handler looks something like:
def change_assumptions
redirect_to(:controller => ''assumptions'',
:action => ''edit'',
:id => session[:property],
:success => {:controller => ''thang'', :id
=> session[:property]})
end
The key is the last bit. I want the redirect url to be /thang/list/1 or
whatever session[:property] resolves to. So, I figured, stuff the redirect
info in a session variable and let nature take its course as follows.
Over in assumptions/edit, everything is fine:
session[:whereto] = params[:success] # stored safe and sound,
right?
Finally in assumptions/update, everything is not fine:
whereto = session[:whereto]
logger.debug("*** whereto => #{whereto}, id =>
#{whereto[:id]},
controller => #{whereto[:controller]}")
Eek! whereto[:id] and whereto[:controller] are nil.
Now, I suspect two things. 1) There must be a better way to do this; and 2)
The problem I¹m currently having has something to do with serializing
hashes.
Any help is appreciated.
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails
This doesn''t answer your problem... but try using the inspect method instead to make sure you are not missing something obvious. For instance: whereto.inspect.to_s # gets the string of your whereto object Or even: session.inspect.to_s # gets all the session content... which is a lot Hope that helps, Tom On 9/21/05, Steve Ross <sross-ju+vs0qJmycyYsO2DCxJlVaTQe2KTcn/@public.gmane.org> wrote:> This is easy, I know, but looking over the wiki and doing some Google > searches turns up nothing. I want to use a related table''s controller to > enter data for its model, then on success, redirect to the parent table''s > controller. An example: > > I have a Thang and each Thang has_one Assumption. When I create a Thang (in > my controller), I create an Assumption with default values (from the > database) and present a nice "modify adjustments" link on the Thang list > page. > > The handler looks something like: > > def change_assumptions > redirect_to(:controller => ''assumptions'', > :action => ''edit'', > :id => session[:property], > :success => {:controller => ''thang'', :id => > session[:property]}) > end > > The key is the last bit. I want the redirect url to be /thang/list/1 or > whatever session[:property] resolves to. So, I figured, stuff the redirect > info in a session variable and let nature take its course as follows. > > Over in assumptions/edit, everything is fine: > > session[:whereto] = params[:success] # stored safe and sound, > right? > > Finally in assumptions/update, everything is not fine: > > whereto = session[:whereto] > logger.debug("*** whereto => #{whereto}, id => #{whereto[:id]}, > controller => #{whereto[:controller]}") > > Eek! whereto[:id] and whereto[:controller] are nil. > > Now, I suspect two things. 1) There must be a better way to do this; and 2) > The problem I''m currently having has something to do with serializing > hashes. > > Any help is appreciated. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Yeah, I did use inspect.to_s, and found the string uninformative. It
didn''t
look like the normal marshalled form I found using IRB. Instead it came out
as a string: ''controllerthangid1''.
I decided on a hack:
In change_assumptions, the redirect_to is changed to:
redirect_to(:controller => ''assumptions'',
:action => ''edit'',
:id => session[:property],
:success => url_for(:controller =>
''thang'', :id =>
session[:property]))
This increases the size of the session variable, but allows me to use a
pre-formed string.
Any comments on this strategy?
On 9/21/05 1:42 PM, "Tom Davies"
<atomgiant-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> This doesn''t answer your problem... but try using the inspect
method
> instead to make sure you are not missing something obvious. For
> instance:
>
> whereto.inspect.to_s # gets the string of your whereto object
>
> Or even:
>
> session.inspect.to_s # gets all the session content... which is a lot
>
> Hope that helps,
> Tom
>
> On 9/21/05, Steve Ross
<sross-ju+vs0qJmycyYsO2DCxJlVaTQe2KTcn/@public.gmane.org> wrote:
>> This is easy, I know, but looking over the wiki and doing some Google
>> searches turns up nothing. I want to use a related table''s
controller to
>> enter data for its model, then on success, redirect to the parent
table''s
>> controller. An example:
>>
>> I have a Thang and each Thang has_one Assumption. When I create a
Thang (in
>> my controller), I create an Assumption with default values (from the
>> database) and present a nice "modify adjustments" link on the
Thang list
>> page.
>>
>> The handler looks something like:
>>
>> def change_assumptions
>> redirect_to(:controller => ''assumptions'',
>> :action => ''edit'',
>> :id => session[:property],
>> :success => {:controller =>
''thang'', :id =>
>> session[:property]})
>> end
>>
>> The key is the last bit. I want the redirect url to be /thang/list/1
or
>> whatever session[:property] resolves to. So, I figured, stuff the
redirect
>> info in a session variable and let nature take its course as follows.
>>
>> Over in assumptions/edit, everything is fine:
>>
>> session[:whereto] = params[:success] # stored safe and
sound,
>> right?
>>
>> Finally in assumptions/update, everything is not fine:
>>
>> whereto = session[:whereto]
>> logger.debug("*** whereto => #{whereto}, id =>
#{whereto[:id]},
>> controller => #{whereto[:controller]}")
>>
>> Eek! whereto[:id] and whereto[:controller] are nil.
>>
>> Now, I suspect two things. 1) There must be a better way to do this;
and 2)
>> The problem I''m currently having has something to do with
serializing
>> hashes.
>>
>> Any help is appreciated.
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>>
>