W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2007

[whatwg] HTML5 and URI Templates

From: Philip Taylor <excors+whatwg@gmail.com>
Date: Mon, 17 Dec 2007 23:35:40 +0000
Message-ID: <ea09c0d10712171535w7502b380p3220e31bd709733b@mail.gmail.com>
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&amp;%7Ca,b%7D"
         template="http://example.org?{-join|&amp;|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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:38 UTC