您的位置：首页 > 理论基础 > 计算机网络

允许表单使用HTTP统一接口的模板

2015-05-20 21:38 309 查看



下面提案中的应用表单的template属性（不是action属性）可以类似是http://search.example.com/search/{q}这样的模板。这样的话，只要再在该表单里定义一个

文本框q，你就可以通过这个应用表单“链接”到http://search.example.com/search/hehe了。


下文转载自：http://blog.welldesignedurls.org/2007/01/11/proposing-uri-templates-for-webforms-2/


Proposing URI Templates for WebForms 2.0

Posted on January
11, 2007 by Mike
Schinkel

I recently had an off-list email conversation
with Ian Hickson, the editor of the Web
Application Hypertext Technology Working Group specifications (i.e. HTML5 andWebForms
2.0). I was proposing to him that the current WebForms 2.0 be draft specification be amended to include a URI
Template in the “action” attribute of
the FORM element. Because I believe so strongly in the benefit of this proposal and because such things are inline with the Well Designed URLs Initiatitve was envisioned to advocate for, I decided to publish it to our blog and reference it in the
WHATWG blog. The following is what I sent to Ian in email:

I really want to see WHATWG incorporate URI Templates for Web Form actions[1].
i.e.:

<form

action="http://foo.com/{make}/{model}/"
method="get">

<input type="text" name="make" />

<input type="text" name="mode" />

<input type="submit" />

</form>


If I type “Honda” and “Civic”, it will do a get to:

http://foo.com/Honda/Civic/


Instead of the only current possibility being something like:

<form

method="get"

action="http://foo.com/cars.php">

<input type="text" name="make" />

<input type="text" name="mode" />

<input type="submit" />

</form>


Which would produce the following for “Honda” and “Civic”:

http://foo.com/cars.php?make=Honda&model=Civic


To which Ian replied in two parts. Here is the first part:

“Why not just write a server-side redirector? That’s a trivial one to write. Four lines of code, maybe 10 if you make the recommended
security checks first. You could also do it with a little bit of JavaScript.”

Unfortunately, a server-side redirector is not an appropriate solution in one case for the use-cases this proposal would address and doesn’t work for two others:

Server-side redirection requires two round trips instead of one. I don’t believe any reasonably competent web architect for a high traffic site would allow a redirect for a high-traffic site. Consider any search engine such as the flagship offering for Ian’s
employer; is Google likely to implement a redirect on every search request? Not likely. Server-side redirection reduces response time (by half?) and increases (doubles?) the number of concurrent requests that servers must handle. Using server-side redirection
would probably also increase bandwidth requirements a measurable amount.

It is not possible via HTTP to redirect the body of a POST. Consequently, the following use-case cannot be duplicated with a server-side redirect:

<form

action="http://www.myblog.com/{topic}/"

method="post">

<select name="topic">

<option value="first">My 1st Post</option>

<option value="second">My 2nd Post</option>

<option value="third">My 3d Post</option>

</select>

<input type="text" name="comment">

<input type="submit">

</form>


For those wanting to create a form to direct to a website they do not control, a server-side redirect is absolutely not an option. For example, assume that I wanted to run a page on my website that lets people navigate to the topics on the WHATWG
blog using a FORM with a SELECT? It’s simply not possible as WebForms 2.0 is currently specified without Javascript (addressed in a moment), but would be easily possible using a template (note I left off the closing “</option>” tags for formatting reasons):

<form

action="http://blog.whatwg.org/{topic}"

method="post">

<select name="topic">

<option value="feed-autodiscovery">

Feed Autodiscovery

</option>

<option
value="text-content-checking">

textContent Checking

</option>

<option value="checker-bug-fixes">

Bug Fixes

</option>

<option

value="significant-inline-checking">

Significant Inline Checking

</option>

<option value="charmod-norm-checking">

Charmod Norm Checking

</option>

<option
value="proposing-features">
Proposing features

</option>

</select>

<input type="submit">

</form>


My belief is having this capability would encourage a lot more linking of this type between pages on the web.

So yes, server-side redirection is possible in some cases but by no means all, and for those cases where it’s possible it is not optimal.

Moving on the Ian’s suggestion to use “a little bit of JavaScript” to meet this use-case, I will admit it is possible to use JavaScript but these are the drawbacks in viewing JavaScript as the solution for this use-case:

JavaScript is simply not allowed in a wide variety of web applications such as wikis, forums, and other sites that solicit community content although many of these do allow HTML elements such as FORM.

Some users disable scripting on certain sites, often by decree of their employers.

Javascript’s cross-browser compatibility issues make it less reliable and people are far less likely to depend on it when money is at stake, and forms are frequently used in those contexts.

“User agents with no scripting support” from Section
1.3 Conformance Requirementsof the Web Applications 1.0
Working Draft (HTML5) that incorporates WebForms 2.0.Need I say more?

Declarative code is far easier to debug than procedural code.

Far more people know HTML than JavasScript given the much greater skill required to master the latter, and that is unlikely to change.

It’s interesting to note that in the preface to the introduction for Section
3 of theWebForms 2.0 Working Draft
of 12 October 2006, the following note is made about how everything that repeating form controls offers can already be done in JavaScript and the DOM. The mere fact that they went to the trouble to include something as complex as repeating controls into HTML5
when it can be done with JavaScript and the DOM implies that well-known patterns in web architecture are better implemented declaratively instead of via JavaScript and the DOM:

Occasionally forms contain repeating sections. For example, an order form could have one row per item, with product, quantity, and subtotal
controls. The repeating form controls model defines
how such a form can be described without resorting to scripting.

Note: The entire model can be emulated purely using JavaScript and the DOM. With such a library, this model could be used and down-level
clients could be supported before user agents implemented it ubiquitously. Creating such a library is left as an exercise for the reader.

So yes it is possible to use JavaScript in many cases, but it no where near optimal. Javascript should not be considered the solution for as well-defined and obvious patterns such as submitting to a clean URL.

To further drive home the value of this proposal, anyone monitoring the REST-discuss
listfor any length of time will see that most REST experts tend toward using (what I call :) well-designed URLs, i.e. URLs where the resource is identified by path instead of query string. With WebForm 2.0′s pending support of PUT and DELETE, it would
be just short of a crime not to include support for posting to clean URLs in WebForms 2.0.

Since having this discussion with Ian via email it was since pointed
out to me on rest-discuss by Mark Baker that my proposal as written would break
the existing web so was a non-starter. For some reason I wasn’t thinking about that, probably because I was more concerned about getting Ian (who I like to call: Mr.
“No“ :) to agree that URI Templates were needed. Still, the solution would be simple.

What follows are my examples from above recast using an optional template attribute that would override the action attribute for WebForms 2.0 compliant browsers. This would of course require the server to accept both query string parameters and clean URLs (and
hopefully do a server redirect from the former to the latter), or the submit could be implemented using Javascript for older browsers when applicable. Note that I didn’t show an example using JavaScript but, as
the WebForm 2.0 spec says “(that) is left as an exercise for the reader”:

<form

action="http://foo.com/model"

template="http://foo.com/{make}/{model}/"

method="get">

<input type="text" name="make" />

<input type="text" name="mode" />

<input type="submit" />

</form>


<form

action="http://www.myblog.com/topic"

template="http://www.myblog.com/{topic}/"

method="post">

<select name="topic">

<option value="first">My 1st Post</option>

<option value="second">My 2nd Post</option>

<option value="third">My 3d Post</option>

</select>

<input type="text" name="comment">

<input type="submit">

</form>


<form

action="http://blog.whatwg.org/topic"

template="http://blog.whatwg.org/{topic}"

method="post">

<select name="topic">

<option value="feed-autodiscovery">

Feed Autodiscovery

</option>

<option
value="text-content-checking">

textContent Checking

</option>

<option value="checker-bug-fixes">

Bug Fixes

</option>

<option

value="significant-inline-checking">

Significant Inline Checking

</option>

<option value="charmod-norm-checking">

Charmod Norm Checking

</option>

<option
value="proposing-features">
Proposing features

</option>

</select>

<input type="submit">

</form>


So in summary I really hope that Ian, who definitely seems to be the gatekeeper for what goes into HTML5 and what doesn’t go into HTML5, can see his way clear to add this feature to WebForms 2.0. If his main issue with it is needing to have it written up for
inclusion in the spec, I’m more than happy to help.

This entry was posted in Call
to Action, Framework
Developers, Open-Source
Participants, Potential, SoapBox,Software
Vendors, Standards
Participants, URI
Templates, Web
App Providers, Web
Developers, Web
Forms. Bookmark the permalink.
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签： 
相关文章推荐
新的分享
章节导航