I suggest taking John's suggestions into close account when we design
the next generation of forms, but I think we should freeze where we're
at now, now, because it's a workable and stable point of convergence
for a large number of currently active clients and servers.
What we've done already is rudimentary in some senses, but it's more
powerful than anything else on the net, it's been proven to work in
the real world for real applications, and it's currently getting a lot
of use.
Cheers,
Marc
> * Although I have CLOS multimethods in my Common Lisp HTTP server, it
> seems like HTTP post is overloaded when one must read random headers
> in order to decide what to do with a form.
>
> * The vocabulary of input types could also use enriching and some
> hierarchical typing along the lines of CLIM presentation types. (Dunno
> if Dave Raggett has got around to looking at this question. He has the
> relevant pointers.See the referenced URL.)
>
> * Incremental local redisplay as function of user choices would be
> highly desirable, but requires a framework for local input-relative
> computations, i.e. selection of one choice changes the set of choices
> offered. These are essentially constraints between queries.
>
> * Addition of the abstraction of a query with a set of values. I hate
> reassembling choices (values) associated with one query from
> n-different ``pseudo queries'' into one actual query.
>
> * Addition of some abstraction on the processing side for people who
> don't have presentation-based automatic form-processing
> infrastructure, i.e, get the values of the form and run my response
> function on them. (Maybe I don't understand what others do here, but
> my impression is that it is every man/woman scripting for
> his/herself.).
>
> If form processing were cleaned up, I expect considerable work could be
> offloaded to the client.
>
> For standard input types, the client would be responsible for returning
> syntactically correct values, freeing the server from having to handle
> type/syntax errors for conforming clients.
>
> At the same time, typed presentations and input types can allow a richer
> variety of gestures for acquiring input from the user, including pointing and
> presentation translation from one type to another. This also opens the
> possibility of tracking what input types are on the user's display.
>
> The important point of this UI technology is that it allows the user to
> directly manipulate program data (appropriately translated) and this maintains
> a tight coupling between the user model and the program model.
>
> These ideas date from a doctoral thesis by Gene Cicarrelli at MIT in the early
> 1980s. Many concepts were implemented in the Symbolics Dynamic Window System
> in 1987. These were then reimplemented (with better engineering and
> simplification) in CLIM the portable Common Lisp Interface Manager, c. 1990.
> To date, we know of no other window system managers which have adopted an
> interaction model of this sophistication.
>
> Before flaming, best to check out an application running a decent
> presentation-based interface, and I'm sure all would agree that it would be a
> really big plus if W3 could exploit at least some of the key concepts.