Kei: after the array input widget, I think the next priority
should be the minimal modifications necessary to
support a reasonable subquery capability. The scenario
I am thinking of is this, with (*#)'s indicating a need
for extension:
o Mosaic displays entity query-form document Q.
o User invokes subbing on a particular entity-valued
field F, perhaps by middle-mouse buttoning it(*1). This results
in a "sub-on-F" URL being sent to the server.
o The server responds with the query-form for the
F entity -- call it R.
o User fills in R, submits. Submit-URL is
sent to server, which responds with subquery results
list L, each item of which has a checkbox and a link
to the corresponding object. User selects some/all items.
Stack is now Q R L.
o Submit on L results in pop(L)(*2), pop(R)(*2), and assignment
of a hidden value to F(*3) listing the selected items,
expressed as a SQL expression. Stack is now Q.
o Submit on Q results in the hidden SQL expression
being included in the URL. (*4)
o Server constructs SQL query including subquery.
Executes query, returns results as list of links.
To do this we need
(*1) input-widget mouse-events, specified as
<INPUT ... SELECT2=action-spec ...>
Select1, Select2, .. being different selection actions --
1-3 would be mouse buttons in a 3-button world.
Action spec is, in general, an URL or a script invocation in a form
scripting language. We can get by with just an URL for this
application.
(*2) FORM submit must be able to cause immediate actions
on the form, with or without server involvement, either
by generalizing the ACTION=URL to ACTION=action-spec
and adding a script language that can express POP and
value storage, or by going through the server and
adding these as directives in HTML. Since at this point
we want to minimize our requirements for a form scripting
language (not because this is not desirable but because
we don't want to implement it) let's take the latter approach.
The form is submitted in the normal manner, but the document
that comes back contains some new HTML commands:
<NOPUSH> #inhibit pushing a new document onto stack
<POP> #pop current document - Mosaic "Back"
<POP>
and
(*3)
<PUT OBJECT="F-name" ATTRIBUTE="SQL" VALUE="SQL-expr">
#store SQL-expr on F's SQL attribute.
This last presumes the internal hash-table for
widget attributes discussed in
http://cgsc.biology.yale.edu/genera.html.
(*4) The search string encoded by a FORM submit must be extended
to include widget-attributes stored in the hash table. For
now we can assume all attributes get included in the
search string, to avoid the need for a message-spec language.
We must, however, devise an extension to the search string
=/& packaging that allows attribute (and input array item)
values to be described.
Cheers. -Stan