I have a detail page that gets called from various places and has a nice readable url like
我有一个从各个地方调用的详细页面,并且有一个很好的可读URL
"www.mypage.com/product/best-product-ever".
The calling pages (list of products) have a more complex url like:
调用页面(产品列表)有一个更复杂的URL,如:
"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
我不能使用javascript
我不希望在URL中有调用页面,因为它会变长
我真的想要页面之间的链接,没有http-post
我不能使用Sessionstate
EDIT: Sessionstate is ruled out, because if there are 2 Windows open, then they would share the same "Back" page information.
编辑:Sessionstate被排除,因为如果有2个Windows打开,那么他们将共享相同的“返回”页面信息。
5 个解决方案
#1
Like Lee said, use the referrer value:
像Lee说的那样,使用referrer值:
<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:
如果您不希望链接中的URL因为它太长,请尝试在URL上运行某种简单的压缩算法,将压缩数据显示为unicode文本,然后将压缩的URL作为参数附加到重定向页面,例如:
<a href="Redirect.aspx?u=compressed_url_goes_here">Back</a>
#2
What about using the referrer header value?
使用referrer标头值怎么样?
#3
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.
创建一个用于缓存“ListResults”的存储库(并将其连接到你喜欢的数据库中,或者只是将它留在服务器的内存中)。简而言之,这个Repo可以做的是存储一个ListResult,它将包含所有用来保持任何给定用户正在查看的列表的当前视图状态的所有内容。这可能包括路由和其他值..但基本上是重定向到过滤和排序列表的特定页面所需的一切。
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.
当ListResult项添加到repo时,会生成一个小的唯一哈希/密钥,它将是url友好的 - 类似于“k29shjk4” - 它会与日期时间戳一起添加到项目中。
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.
ListResults仅在列表离开默认视图时保持不变(即没有过滤,排序和第1页) - 这将有助于提高性能。
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.
ListResult项可能永远不会被使用,但特定列表视图上的所有详细操作链接都将ListResult.Key哈希值添加到路由中。所以,是的,它最终可能会成为一个查询字符串,但它会很短(网址友好),如果你想更多地混淆路线,你可以进一步整理它。
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.
为了“返回”到列表的导航,您可能需要一个新的小型控制器,它只接受ListResult.Key哈希值并重定向/重新创建列表视图的状态(包括分页,过滤和排序)。回购。
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.
所以到目前为止我们已经满足了这些要求:url中没有调用页面(从某种意义上说它不是整个页面 - 只是对它的哈希查找);没有POST,没有会话,没有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.
要阻止ListResult repo变大(并且危险:如果你将它保存到数据库中),你可以使用ASP.NET后台服务定期通过时间戳修剪'旧'路由..并'extend'通过新控制器请求时,通过向ListResult项目的戳记添加时间来持续使用的路由的生命周期。如果用户想要永久链接到列表视图,则无需无限期地保留路由,他们可以为长列表路由本身添加书签。
hope this helps somehow
希望这会有所帮助
#4
Do you have a cookie?
你有饼干吗?
If so, you can put it in there, or use it to create your own session state.
如果是这样,您可以将其放在那里,或使用它来创建自己的会话状态。
#5
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?
我认为这更像是“返回结果”,然后是一个通用的“< <返回”链接,因为你会期望通用的反向链接返回到遗传列表,而不是你描述的严重过滤的列表,对吧?< p>
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.
我不知道这是否属于你的“无帖子”状态,但我能看到的唯一选择是将详细操作设为仅POST([AcceptVerbs(HttpVerbs.Post)])并包含另一个参数,如string fullRoute将转换为“返回结果”详细信息页面上的“链接”。重载缺少fullRoute参数的Detail操作,并将重载操作作为GET操作,以便不需要POST fullRoute值(当用户可以使用'generic'“Back”链接时)。这应该为“详细信息”页面的“通用”GET请求和POST请求提供服务,后者将包含已过滤列表的特定“返回结果”链接。
#1
Like Lee said, use the referrer value:
像Lee说的那样,使用referrer值:
<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:
如果您不希望链接中的URL因为它太长,请尝试在URL上运行某种简单的压缩算法,将压缩数据显示为unicode文本,然后将压缩的URL作为参数附加到重定向页面,例如:
<a href="Redirect.aspx?u=compressed_url_goes_here">Back</a>
#2
What about using the referrer header value?
使用referrer标头值怎么样?
#3
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.
创建一个用于缓存“ListResults”的存储库(并将其连接到你喜欢的数据库中,或者只是将它留在服务器的内存中)。简而言之,这个Repo可以做的是存储一个ListResult,它将包含所有用来保持任何给定用户正在查看的列表的当前视图状态的所有内容。这可能包括路由和其他值..但基本上是重定向到过滤和排序列表的特定页面所需的一切。
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.
当ListResult项添加到repo时,会生成一个小的唯一哈希/密钥,它将是url友好的 - 类似于“k29shjk4” - 它会与日期时间戳一起添加到项目中。
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.
ListResults仅在列表离开默认视图时保持不变(即没有过滤,排序和第1页) - 这将有助于提高性能。
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.
ListResult项可能永远不会被使用,但特定列表视图上的所有详细操作链接都将ListResult.Key哈希值添加到路由中。所以,是的,它最终可能会成为一个查询字符串,但它会很短(网址友好),如果你想更多地混淆路线,你可以进一步整理它。
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.
为了“返回”到列表的导航,您可能需要一个新的小型控制器,它只接受ListResult.Key哈希值并重定向/重新创建列表视图的状态(包括分页,过滤和排序)。回购。
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.
所以到目前为止我们已经满足了这些要求:url中没有调用页面(从某种意义上说它不是整个页面 - 只是对它的哈希查找);没有POST,没有会话,没有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.
要阻止ListResult repo变大(并且危险:如果你将它保存到数据库中),你可以使用ASP.NET后台服务定期通过时间戳修剪'旧'路由..并'extend'通过新控制器请求时,通过向ListResult项目的戳记添加时间来持续使用的路由的生命周期。如果用户想要永久链接到列表视图,则无需无限期地保留路由,他们可以为长列表路由本身添加书签。
hope this helps somehow
希望这会有所帮助
#4
Do you have a cookie?
你有饼干吗?
If so, you can put it in there, or use it to create your own session state.
如果是这样,您可以将其放在那里,或使用它来创建自己的会话状态。
#5
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?
我认为这更像是“返回结果”,然后是一个通用的“< <返回”链接,因为你会期望通用的反向链接返回到遗传列表,而不是你描述的严重过滤的列表,对吧?< p>
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.
我不知道这是否属于你的“无帖子”状态,但我能看到的唯一选择是将详细操作设为仅POST([AcceptVerbs(HttpVerbs.Post)])并包含另一个参数,如string fullRoute将转换为“返回结果”详细信息页面上的“链接”。重载缺少fullRoute参数的Detail操作,并将重载操作作为GET操作,以便不需要POST fullRoute值(当用户可以使用'generic'“Back”链接时)。这应该为“详细信息”页面的“通用”GET请求和POST请求提供服务,后者将包含已过滤列表的特定“返回结果”链接。