Re: Refocusing on HTML

Paul Prescod wrote:
> 
> 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.
> 
I am advocating MSELECT ias a public service because I think the 
Web needs it and organizations large and small as well as the general
WWW public will benefit from it.  My own project will probably resort to
a Java applet or a tables & frames solution.

> 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).
> 
Great idea!  But how about making it a FORM element like INPUT or SELECT 
called, perhaps, WIDGET.  That way you could have multiple WIDGETs in a
FORM.  The WIDGET would have the same attributes and syntax as the existing
HTML 3.2 APPLET element, but the browser would query the WIDGET's applet for 
its data when the form is submitted just as you suggested.  What do you 
think?

In the mean time, however, I am still advocating the MSELECT.
====================================================================
Gregory A. Smith
303-541-6006
gasmith@advtech.uswest.com

Received on Thursday, 5 September 1996 13:08:59 UTC