How do I make a "back" link?

Question

I have a detail page that gets called from various places and has a nice readable url like

"www.mypage.com/product/best-product-ever".

The calling pages (list of products) have a more complex url like:

"www.mypage.com/offers/category/electronic/page/1/filter/manufacturer/sony/sort/price" and

"www.mypage.com/bestseller/this-week".

How can I make a backlink from the detailpage to the calling product list?

• I cannot use javascript
• I don't want to have the calling page in the URL, because it gets to long
• I really want links between pages, no http-post
• I cannot use Sessionstate

EDIT: Sessionstate is ruled out, because if there are 2 Windows open, then they would share the same "Back" page information.

Answer 1

Do you have a cookie?

If so, you can put it in there, or use it to create your own session state.

Answer 2

I think this is more like a "Back to results" then a generic "<< back" link, because you would expect the generic back link to return to the genetic list, not the heavily filtered list you described, right?

I don't know if this falls into your "no post" condition, but the only option I can see is having the Detail action be POST-only ([AcceptVerbs(HttpVerbs.Post)]) and include another parameter like string fullRoute which is converted to the 'link' on the detail page for "Back to results". Overload the Detail action missing the fullRoute param and have the overloaded action be a GET action so that the POST fullRoute value is not required (for when users are ok with the 'generic' "Back" link). This should serve both 'generic' GET requests to the Detail page and the POST request which will include the specific "Back to results" link for the filtered list.

Answer 3

What about using the referrer header value?

Answer 4

Like Lee said, use the referrer value:

<a href="<%= Html.Encode(Request.UrlReferrer.ToString()) %>">Back</a>

If you don't want the URL in the link because it's too long, try running some sort of simple compression algorithm over the URL, display the compressed data as unicode text and then append the compressed URL as a parameter to a redirect page, e.g:

<a href="Redirect.aspx?u=compressed_url_goes_here">Back</a>

Answer 5

Here's a crazy idea that will require a fair but of work and may not be healthy for performance (depending on your users).. but here we go:

Create a repository for caching 'ListResults' (and wire it to persist to the DB of you like.. or just leave it in memory on the server). In short what this Repo can do is store a ListResult which will include everything to persist the state of the current view of the list any given user is looking at. This might include routes and other values.. but essentially everything that is needed to redirect back to that specific page of the filtered and sorted list.

As the ListResult item is added to the repo a small unique hash/key is generated that will be url friendly - something like this "k29shjk4" - it is added to the item along with a datetime stamp.

ListResults are only persisted from the moment a list gets off the default view (ie. no filtering, sorting and Page 1) - this will help in a small way for performance.

A ListResult item may never actually get used but all detail actionlinks on the particular list view have the ListResult.Key hash value added to the route. So yes, it might end up as a querystring but it will be short (url friendly) and if you wanna mess with routes more, you can tidy it up further.

For navigation "back" to the list, you may need a new small controller which accepts simply the ListResult.Key hash value and redirects/re-creates the state of the list view (paging, filtering and sorting included) from the lookup in the repo.

So we have met the requirements so far: no calling page in the url (in the sense that its not the whole page - just a hash lookup of it); no POSTing, no sessions, no js.

To stop the ListResult repo from getting to big (and dangerous: if you persist it to the DB), you can use a ASP.NET background service to periodically prune the 'old' routes by way of the timestamp.. and 'extend' the life of routes that are continuously being used by adding time to the stamp of a ListResult item when it's requested via the new controller. No need to persist a route indefinitely coz if a user wants a permalink to a list view, they can bookmark the long list route itself.

hope this helps somehow