Render and routes


#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

On Feb 13, 12:02 am, “Sheldon H.” removed_email_address@domain.invalid wrote:

How about this?

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

Ciao,
Sheldon.

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


#3

On Feb 13, 7:27 am, “Dean” removed_email_address@domain.invalid wrote:

Something like:

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

How about this?

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

Ciao,
Sheldon.


#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 ?


The intuitive mind is a sacred gift and the rational mind is a faithful
servant. We have created a society that honors the servant and has
forgotten the gift.
–Albert Einstein


#6

On Feb 15, 8:44 pm, “Aaron” removed_email_address@domain.invalid wrote:

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

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?


Any sufficiently advanced technology is indistinguishable from magic.
– Arthur C. Clarke