- From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Date: Wed, 04 Sep 1996 10:50:30 -0400
- To: "Greg A. Smith" <gasmith@advtech.uswest.com>
- Cc: Lee Daniel Crocker <lee@piclab.com>, www-html@w3.org
At 04:33 PM 9/3/96 -0600, Greg A. Smith wrote: >But a Java component isn't an HTML FORM element. In order to >be used with the HTML FORM methodology, in which the selected >OPTION row is communicated back to the application via a NAME=VALUE >pair in the query string, the element must be integrated into the >existing technology. That's a good point. I apologize for having not thought it through completely. Still, Java offers the possibility of bypassing CGI altogether. Surely every major database manufacturer wants this to be as easy as you want it to be. That doesn't mean I don't think it is worth standardizing, I am just trying to think of a way for you to get your project while you lobby browser vendors. There should be a way to handle this issue in a more general sense. There are many worthy, useful widgets ranging from slider bars to "datawindows" and there should be a faster way to deploy them than to get browser support for new HTML form elements. What if there were a <FORM type="applet">? The browser would query the applet for its data when the form is submitted. The communication mechanism between the browser and the applet would be defined by the applet language vendor (i.e. in Java, it would be an overridable method on the "applet" class). Paul Prescod
Received on Thursday, 5 September 1996 13:08:46 UTC