Re: PROPOSAL FOR A MULTI-COLUMN SELECT ELEMENT WITHIN A FORM FIELD-Reply

Jim Taylor wrote:
> 
> Your proposal was posted 5 hours ago and you're upset that we're
> "utterly ignoring" it? Many list members haven't even read it yet!
> 
> Here's my response:
> 
> You say (in a later message) that you wish HTML "provided the basic
> building blocks for the building of WWW front-ends to applications." In
> this analogy (a-la-Lego), your proposal looks to me more like a special
> tan-colored, angled, scalloped roof block, or a see-though, curved
> windshield block, than a basic building block.
> 

I call the proposed element, MSELECT, a basic building block because
it is basic to every database graphical front-end tool that I have ever
used or heard of (Ingres Windows 4GL, Paradox, Powerbuilder, Access,
FoxPro to name a few). Trying to build the typical database front-end
without this widget is a nightmare of kludges and compromises.

> Your proposal goes too far beyond the basics, yet paradoxically not far
> enough. What about mutually exclusive and inclusive selections (i.e.
> check one item and others are automatically selected or unselected)?
> What happens if someone wants graphics in the list. Or checkboxes? Or
> what about spanning parts of rows so duplicate information isn't
> repeated? Or... I think you get my drift.
> 

My solution does not go beyond the basics.  It maintains consistency with
the current syntax for SELECT and TABLE which it resembles and is easily
comprehensible.  The needed functionality is almost there now and can be 
kludged in a UNIX environment using the existing SELECT widget.  This
element will make this basic functionality available to all systems without
kludges.

As for your drift about gilding this element with various add-ons, that
argument could be used against any existing or proposed element in HTML
(see almost any current thread in this mailing list).

> In my opinion the basic building blocks are already there. I agree that
> there's a need to do what you describe, but "application support" like this
> is what Java, ActiveX, LiveObjects, etc. are for.
> 

The functionality provided by MSELECT could be implemented via Java or
some other language, but then you are forced to dispense with the HTML
FORM field as an interface and build a custom interface for each 
application.  Instead of using a simple HTML FORM element and the 
existing FORM methodology which is available to all Web application
developers, each application developer is forced to create a new front-end 
applet from scratch and basically re-invent the existing FORM protocol 
and methodology in a non-standard, totally custom way.  It is an awfully
long way to have to go, especially when 95% of what we need is already
there (99% on Unix).  Why not go all the way?

The absence of a multi-column SELECT element is the only major impediment 
to building robust relational database applications on the web.

====================================================================
Gregory A. Smith
303-541-6006
gasmith@advtech.uswest.com

Received on Friday, 30 August 1996 20:12:23 UTC