Re: Forms support in clients

Gavin Nicol (gtn@ebt.com)
Sun, 25 Sep 1994 16:45:04 +0100

>> I don't understand what you're trying to do. If you're trying to give
>> names to the variables in a form, doesn't the NAME tag do that already?
>> Or are you trying to place some sort of default text in the text entry
>> field (which can be done using VALUE)?
>
>No - he wants documents that can be more like programs. basically he
>wants to display the form, have the user fill in what doc he
>would like (as an example) and then have the browser do a text
>substitution on the ACTION part before performing the GET.

While this is basically correct, I would like to see the text
substitution be entirely general so that it could support basically
any URL format, including server-specific extensions. The idea could
be made to work with current servers by doing a substitution like:

foo?text=$text

My biggest complaint is that this forces a particular URL format on
all servers, and that format does double duty as the query format.

>The current requires-no-changes way is to use a script for this
>which accepts two parameters and issues a redirect for them.

At considerable expense I might add. I should mention that I think
this will be even more useful once more servers start supporting PUT
et al. and even more so once multiple transactions are allowed in
HTTP. For example, if I have a server that supports PUT and
versioning, a natural URL format might be:

http://foo/document_path/version_path ( http://foo/mydoc/11/2)

but if we want to have a form asking what new version number to
assign, or to check out, we would have to use the URL format:

http://foo/mydoc?version="11.2"

which isn't quite as "natural". My personal opinion is that forms,
queries, and fragment ID's are where URL's really are quite weak now.
I'm not sure that any *defined* system will work well in *all*
situations, so it seems better to support something that will give us
flexibility to adapt URL's and forms as needed.

I think overall the idea would be a win, and I'm very surprised that
this wasn't done initially as implementation would be very little more
complicated that the current forms system. Now it's almost too late to
make changes because of the inertia...