[5886] in www-talk@info.cern.ch

home help back first fref pref prev next nref lref last post

Re: Forms support in clients

daemon@ATHENA.MIT.EDU (Dave Raggett)
Wed Sep 28 20:28:41 1994

Date: Thu, 29 Sep 1994 01:25:23 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: dsr@hplb.hpl.hp.com
From: Dave Raggett <dsr@hplb.hpl.hp.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>

This issue of client-side scripting is something I tackled quite a while
back now. For HTML the approach is simple, you add a SCRIPT attribute to
the FORM element that specifies the URL of a script. The browser then
uses the Accept header to specify which scripting languages it supports.

What we should be spending air time on is the abstract API between
the browser and the script interpreter. Trusted scripts can be recognised
as such as they will carry a digital signature plus certificates in the
HTTP header. I will therefore concentrate on untrusted scripts:

    o   scripts can read a set of browser environment variables
        e.g. the user's name, email address, time of day etc.

    o   scripts can read the contents of form fields and their
        associated status flags (in-error, disabled).

    o   scripts can set the contents of form fields and their
        associated status flags (in-error, disabled).

    o   scripts can get/set the current focus

    o   scripts are passed various classes of events, e.g.
        get/release focus, mouse clicks, keyboard events

    o   scripts can set/clear a system error message

    o   scripts can access a few well chosen library routines

    o   scripts are limited in the amount of memory or screen
        resources they can consume

    o   scripts interpreters are linked to the browser via
        a (scripting) language independent API

    o   form fields belong to a well defined set of classes
        but there is a way to define new classes that are
        painted by the script

    o   scripts can't send messages

I don't have time to refine this, and would love to see other people
work together on refining this into a detailed proposal, rather than
arguing on which language to choose.

p.s. why not Visual Basic :)
--
Best wishes,

Dave Raggett

-----------------------------------------------------------------------------
Hewlett Packard Laboratories              email: dsr@hplb.hpl.hp.com
Filton Road                               tel:   +44 272 228046
Stoke Gifford                             fax:   +44 272 228003
Bristol BS12 6QZ
United Kingdom

home help back first fref pref prev next nref lref last post