> Copies to www-talk and www-html.
> Sorry to be a bore but this is important and a lot simpler than some people
> seem to think.
Always nice to know.
But then, Simple != Easy.
In fact (as any AI person knows) Simple often == Bloody hard.
> Adding a lookup attribute to fields requires, in my earlier example, simply
> a word "lookup" and a numeric value n. The "lookup" tells the browser that
> there is a reference file against which to verify any input. The numeric
> value tells the browser to search the file attached to the field when n
> characters have been entered in the input field. If a hit is scored then
> the resulting record is pulled out of the file and put into the input
> field.
Well, where is the file stored? Presumably it's out on the net somewhere
(sample place the form came from? Probably, but maybe not - maybe there's
a canonical list of ZIP codes somewhere.
If (as you assume below) the files are local - how do they appear?
I am not about to download a 10 MB database of widget descriptions just
to have a field lookup.
If I can assume that the form needs to do a net access - then
we can assume a form may need to do several such calls (if there
are several fields).
Therefore, (in order to speed things up - all those net accesses take time)
why not just let the server handle it - and report errors appropriately,
or even return another filled out form with the partially fields
filled out.
For short lists, you can just as easily use the existing FORM features.
For long lists - you need to talk to the server again, and therefore
should delay that to SUBMIT time.
Ok - assuming you want to implement it, may I suggest:
add a LOOKUP=urlstring
which will call the LOOKUP with the NAME=whatever typed so far if the user
presses a visual feature or somesuch (remember that net-lag is
non-trivial and doing a new lookup after every new keystroke is not
feasible.
> If they are refenced in the <input ...>
> then they can be delivered to the browser as part of the package. All the
> browser has to do is open the relevant file when focus hits the field and
> do a dynamic read when 4 or 5 characters have been entered, if there isn't
> a hit then the field could be blanked and the user told why - no hit.
> Seems pretty simple for the browser, simple for the server but
> gives people like me a powerful tool with which to buuild "clever" forms.
If you need clever forms, why not use a more suitable tool?
Christian "Perl hacker"