Best Practice for Returning to Calling Page?


#1

I have a partial, it’s a shopping cart display, it’s designed to appear
on several different pages of my site.

One of the buttons on the shopping cart empties the cart, and then I
want the calling page to redisplay.

In other words, the cart controller needs to return the visitor to the
same page – however since the cart could appear on any given page, this
has to be dynamic, not hard-coded.

So the solution I’m considering is to use params[:controller],
params[:action], and params[:id] as a unique identifier of the calling
page. I’m assuming this will work but I want to be sensitized to any
‘gotchas’ before I code this.

If anyone can suggest a better practice I’d appreciate it, thanks.


#2

@request.request_uri

The above will hold the uri of the calling page.

charlie bowman
www.recentrambles.com

Gaudi Mi wrote:

I have a partial, it’s a shopping cart display, it’s designed to appear
on several different pages of my site.

One of the buttons on the shopping cart empties the cart, and then I
want the calling page to redisplay.

In other words, the cart controller needs to return the visitor to the
same page – however since the cart could appear on any given page, this
has to be dynamic, not hard-coded.

So the solution I’m considering is to use params[:controller],
params[:action], and params[:id] as a unique identifier of the calling
page. I’m assuming this will work but I want to be sensitized to any
‘gotchas’ before I code this.

If anyone can suggest a better practice I’d appreciate it, thanks.


#3

charlie bowman wrote:

@request.request_uri

The above will hold the uri of the calling page.

charlie bowman
www.recentrambles.com

Gaudi Mi wrote:

I have a partial, it’s a shopping cart display, it’s designed to appear
on several different pages of my site.

One of the buttons on the shopping cart empties the cart, and then I
want the calling page to redisplay.

In other words, the cart controller needs to return the visitor to the
same page – however since the cart could appear on any given page, this
has to be dynamic, not hard-coded.

So the solution I’m considering is to use params[:controller],
params[:action], and params[:id] as a unique identifier of the calling
page. I’m assuming this will work but I want to be sensitized to any
‘gotchas’ before I code this.

If anyone can suggest a better practice I’d appreciate it, thanks.

url_for :overwrite_params => {}

it’s intended to return the current uri with only specific parts
changed, the action or id or what ever… but don’t pass any changes :wink:


#4

For those that are interested, I found that the redirect_to method can
be used like this:

redirect_to :back

which will take one back to the requesting page.

Michael G. wrote:

charlie bowman wrote:

@request.request_uri

The above will hold the uri of the calling page.

charlie bowman
www.recentrambles.com

Gaudi Mi wrote:

I have a partial, it’s a shopping cart display, it’s designed to appear
on several different pages of my site.

One of the buttons on the shopping cart empties the cart, and then I
want the calling page to redisplay.

In other words, the cart controller needs to return the visitor to the
same page – however since the cart could appear on any given page, this
has to be dynamic, not hard-coded.

So the solution I’m considering is to use params[:controller],
params[:action], and params[:id] as a unique identifier of the calling
page. I’m assuming this will work but I want to be sensitized to any
‘gotchas’ before I code this.

If anyone can suggest a better practice I’d appreciate it, thanks.

url_for :overwrite_params => {}

it’s intended to return the current uri with only specific parts
changed, the action or id or what ever… but don’t pass any changes :wink:


#5

However this requires the HTTP_REFERER to be set in the request. I’ve
seen cases where it isn’t. Don’t know if this is only a webrick thing
(where I just reproduced it to be sure I’m not hallucinating…) or
not. Here’s part of the error message returned to the browser (in
development mode):

No HTTP_REFERER was set in the request to this action, so redirect_to
:back could not be called successfully. If this is a test, make sure
to specify @request.env[“HTTP_REFERER”].

Anyone know when and if this is set and “guaranteed” to be available?

dean

redirect_to :back


Dean W.
http://www.aspectprogramming.com
http://www.newaspects.com
http://www.contract4j.org


#6

Gaudi Mi wrote:

For those that are interested, I found that the redirect_to method can
be used like this:

redirect_to :back

which will take one back to the requesting page.

DOH!!!

That just saved me loads of time

Thanks Dude!


#7

“Dean” == Dean W. removed_email_address@domain.invalid writes:

However this requires the HTTP_REFERER to be set in the request. I’ve
seen cases where it isn’t. Don’t know if this is only a webrick thing

It’s a web browser thing. The referrer information is entirely in the
hands of the client, and can never be trusted or relied upon to exist.
Some browsers (like Firefox) have the ability to turn it off built in,
and for other browsers some people run local proxies that strip the
information out.

	     Calle D. <removed_email_address@domain.invalid>
	 http://www.livejournal.com/users/cdybedahl/

“Now I want to hear the GPL done as a Gregorian chant. Or maybe a
rapper’s
interpretation of the BSD license.” – Russ Allbery, BofhNet