- From: Philip Taylor <excors+whatwg@gmail.com>
- Date: Mon, 17 Dec 2007 23:35:40 +0000
On 17/12/2007, James M Snell <jasnell at gmail.com> wrote: > It should be possible for us to also do something like: > > <form action="http://example.org/form_processor" > template="http://example.org?{-join|&|a,b}" > method="POST"> > <input name="a" type="text" /> > <input name="b" type="text" /> > <input name="c" type="text" /> > <input name="d" type="text" /> > </form> > > [...] > > HTML5 Post: > > POST /example.org?a=w&b=x > Host: example.org > ... > c=y&d=z > > HTML4 Post: > > POST /form_processor > Host: example.org > ... > a=w&b=x&c=y&d=z > > - James Presumably people will use more than one templated form on their site, but won't want lots of separate form_processors, so they would have to use <form action="http://example.org/form_processor?{-join|&|a,b}" template="http://example.org?{-join|&|a,b}" method="POST"> or something theoretically more correct like <form action="http://example.org/form_processor?%7B-join%7C&%7Ca,b%7D" template="http://example.org?{-join|&|a,b}" method="POST"> and then they can drop in a standard generic form_processor script to handle everything automatically. Most legacy browser users could be handled by a script which adds onsubmit hooks to rewrite the 'action' attribute before submitting. (I assume that'd work correctly in current browsers, but haven't tested it). That would avoid the need for repeating the template URI twice (with the associated risks of typing one of them wrong and not noticing), if you don't want to handle scriptless users. (How would the script know when it should do the rewriting, and when it should leave everything to the browser? There's no obvious feature test it can perform.) Wondering about why this feature would be used: If everyone who uses template URIs uses these backward-compatibility additions (which they have to, unless they have no users), why would a browser implement native support for template URIs? (The reason I can think of is that it provides a slightly better user experience, because you can go directly to the destination rather than being delayed by a round-trip to form_processor, but that's no faster than the scripted approach.) If everyone who uses template URIs has to use these backward-compatibility additions, why would they go to that effort instead of using some server-side redirection logic to perform the desired processing at the normal non-templated ugly URI? (Maybe it makes the system cleaner if the server code has a nice URI-based API and the client code does the mapping onto that, but I have no idea how much difference it really makes. More significantly, it allows the direct use of external resources that have sufficiently nice URIs but don't have an equivalent GET/POST form-accessible API. I haven't seen any other obvious useful uses yet.) -- Philip Taylor excors at gmail.com
Received on Monday, 17 December 2007 15:35:40 UTC