通过“查看参数"功能实现可书签性

本文介绍了通过“查看参数"功能实现可书签性的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

通过将includeViewParams=true查询参数与JSF隐式导航一起使用，是否可以实现书签功能?如果是，那怎么办?

Is bookmarkability achievable though using the includeViewParams=true query parameter with JSF implicit navigation ? If yes, then how ?

推荐答案

首先，我们需要了解可标记性"的确切含义和includeViewParams的确切含义.这样可以更好地理解两者结合的效果.

First we need to understand what exactly "bookmarkability" is and what exactly includeViewParams does. This way the effect of the combination of both can be better understood.

可书签性涉及HTTP请求URL的确切形式，如您在浏览器的地址栏中看到的那样.正是最终用户存储在其书签中和/或将复制粘贴作为链接的其他地方(例如论坛，聊天框，某些社交媒体或只是新的浏览器窗口/标签等)所使用的URL.或将URL复制粘贴到浏览器的地址栏中，则默认情况下会触发HTTP GET请求.如果每次结果均完全相同(离开授权/身份验证以及页面的搜索结果，最新消息等的时间敏感性)，那么我们可以讨论可添加书签的内容网址.技术术语为一个幂等 HTTP请求".

Bookmarkability concerns the HTTP request URL in its exact form as you see in the browser's address bar. It's exactly the URL as the enduser would store in its bookmarks and/or would copypaste as a link elsewhere, such as a forum, a chatbox, some social medium, or just a new browser window/tab, etc. When a link is followed or an URL is copypasted into browser's address bar, then by default a HTTP GET request will be fired. If the result is exactly the same everytime (leaving authorization/authentication and the time-sensitive nature of the page —search results, last news, etc— outside consideration), then we can talk about a bookmarkable URL. The technical term is "an idempotent HTTP request".

但是，如果最终用户事先在该URL上提交了POST表单，但未执行重定向，则该URL不一定是可书签的.提交的表单数据未反映在URL中.将URL复制粘贴到新的浏览器窗口/选项卡中不一定会产生与提交表单后完全相同的结果.这样，这样的URL就不能加书签了. POST不是幂等的.这就是通过命令链接进行逐页导航的原因.

If the enduser has however submitted a POST form on that URL beforehand, which hasn't performed a redirect, then the URL is not necessarily bookmarkable. The submitted form data is not reflected in the URL. Copypasting the URL into a new browser window/tab may not necessarily yield exactly the same result as after the form submit. Such an URL is then not bookmarkable. POST is not idempotent. That's why page-to-page navigation by commandlinks is bad.

可标记性通常是通过URL路径和/或查询参数的特定构造来实现的.如果您使用的是Google，则可以使用q查询字符串参数来将搜索结果添加为书签.

Bookmarkability is usually achieved by a specific construct of the URL path and/or query parameters. If you look at Google, the search results are bookmarkable thanks to the q query string parameter.

google/search?q=bookmarkability

在JSF术语中，可以通过 <f:viewParam> :

In JSF terms, those request parameters can be set (and converted and validated) via <f:viewParam>:

<f:metadata> <f:viewParam name="q" value="#{bean.query}" /> <f:viewAction action="#{bean.search}" /> </f:metadata>

如果您需要执行例如分页，并且希望将URL设置为书签，则可以添加另一个请求参数:

If you need to perform for example pagination, and you'd like to keep the URL bookmarkable, then you could add another request parameter:

google/search?q=bookmarkability&start=10

使用

<f:metadata> <f:viewParam name="q" value="#{bean.query}" /> <f:viewParam name="start" value="#{bean.start}" /> <f:viewAction action="#{bean.search}" /> </f:metadata>

includeViewParams="true"基本上在生成的GET链接中包括所有这些视图参数.在此帮助下，分页链接可以看起来像这样，而无需重复q参数:

The includeViewParams="true" basically includes all of those view parameters in the generated GET link. With help of this, the pagination links can then look like this without the need to repeat the q parameter:

<h:link value="1" outcome="search" includeViewParams="true"> <f:param name="start" value="#{null}" /> </h:link> <h:link value="2" outcome="search" includeViewParams="true"> <f:param name="start" value="10" /> </h:link> <h:link value="3" outcome="search" includeViewParams="true"> <f:param name="start" value="20" /> </h:link> ...

(当然是由某些<ui:repeat>左右生成的)

(of course generated by some <ui:repeat> or so)

使用q=bookmarkability进入页面时，将产生以下链接

When entering the page with q=bookmarkability, this will produce the following links

/search.xhtml?q=bookmarkability /search.xhtml?start=10&q=bookmarkability /search.xhtml?start=20&q=bookmarkability

这些都是可添加书签的URL，includeViewParams使得创建URL更加方便.

Those are bookmarkable URLs and the includeViewParams made creating them more convenient.