Render and routes

rubyonrails-talk
1

I have a common situation: a create operation fails and so I want to render the new view again for correction. Wouldn't be too hard to render the right thing, but I need to tack an extra parameter onto the url. I can't quite figure how to do this with named routes.

Something like:

render hash_for_new_user_url(), :username => params[:username]

TIA, --Dean

2

How about this?

  render hash_for_new_user_url().merge({:username => params[:username]})

Ciao, Sheldon.

3

Thanks Sheldon, that made the right hash, but it must not be what I'm looking for.

Controller:

render hash_for_edit_fermentable_ingredients_url().merge(:fermentable_name => params[:fermentable_name] )

Renders without the extra parameter.

Rendering layoutfalseactioneditfermentable_nameGerman Munichonly_pathfalseuse_routeedit_fermentable_ingredientcontrollerfermentable_ingredients within layouts/application Rendering fermentable_ingredients/edit

Looks like it's using the extra stuff for the layout instead of tacking it on to the request.

Thanks, --Dean

4

You don't need to pass extra parameters when doing a render. You are not calling a url, you are overriding the default rhtml file by explicitly calling another one. If you want to pass something into that view file then just stick it into an @ variable.

When calling redirect_to you are constructing a url that will be passed to another controller action. In that case you may want to tack on extra parameters.

Aaron

5

Aaron said the following on 02/15/2007 11:44 PM:

When calling redirect_to you are constructing a url that will be passed to another controller action.

Does that mean a redirect_to() doesn't actually go out to the client browser and back again? Ate you saying that its passed along internally and the other controller sees it "as if" it came from the browser?

In that case does redirect_to() interact with the routes.rb ?

6

Ah, of course. I have it straightened out now. Thanks.

--Dean

7

Does that mean a redirect_to() doesn't actually go out to the client browser and back again?

redirect_to() DOES go back to the browser and redirect it to a new page. However, render() does not.

In that case does redirect_to() interact with the routes.rb ?

Yes, redirect_to() is routed just like any other request.

Aaron

8

Aaron said the following on 02/16/2007 01:03 AM:

Does that mean a redirect_to() doesn't actually go out to the client browser and back again?

redirect_to() DOES go back to the browser and redirect it to a new page. However, render() does not.

In that case does redirect_to() interact with the routes.rb ?

Yes, redirect_to() is routed just like any other request.

Ah. That was what was making a mess of my error handling.

I had, as I mentioned in an earlier post, tried an "Oops" handler so that it could handle a vast number of partials & views for the various error conditions and have a "method_missing" for the ones I hadn't got around to doing a specific view for.

But without some line in the routes.rb is won't work.

OBTW: I'm using routes.rb as a security tool - sort-of - by limiting the legal routes and format of the parameters. I'm strenuously trying to avoid 'leaking' information about internals - names of controls, actions - so that hackers cant try, for example, stepping through ID numbers.

So am I better with   if cando = false      redirect_to( :controller => Oops,                   :action => 'accessdenied',                   :type => 'alarm',                   :message => 'no_permission_to_view',                   :return_to => saved_url,         )   else        ....   end

or with

  if cando false       render(:template => "oops/accessdenied"              :type => 'alarm',                    :message => 'no_permission_to_view',                   :return_to => saved_url,         )   .....

Hmm. Perhaps I need to find another way to do the hadnling of the 'saved_url'.

Advice?