> next up is multiline text entry
> areas (which will require an alternative form submission method --
> don't want to be packing 10K of text into a URL).
Great!! That one is very important for something I want to do, which
is basically set up an input form that creates an HTML doc at the
same time as it sends the parameters out (well I guess you could
just say it is sending the parameters to another server that is
putting them into HTML ... and tagging the non-HTML "logical tag"
items I mentioned). Is that perhaps a candidate for the
"alternative form submission method" -- hmm ... guess you would
have to build a little "server" functionality into the client
so it could "serve" the HTML back to the query server in the form
of an HTML document plus parameters (and/or "logical tags"), and
then have an HTML and logical tag filter in the interface of your
query server.
We definitely need multiline entry for some things, but
perhaps for "input form" apps that create documents or big
data objects with really large text and graphics and multi-media
stuff it would be better to have a capability to "attach" files to
the other stuff being sumitted from the form. That could be
along the lines of the "query" or form results creating an HTML
doc, with in-line images, links, etc.
This is getting closer and closer to an HTML editor of sorts!
But that (using a Mosaic form to create an HTML document, rather
than a free-form HTML editor -- especially for novices) seems
appropriate for VERY structured types of data objects, such as
technical reports. Our applications include, e.g., Failure
Analysis reports, which contain several well-defined fields like
"part number", "manufacturer (CAGE Code)" etc., plus the main
body -- lots of text -- plus photos. This is pretty typical of
a lot of engineering publications, for which a certain amount of
standardization would be very useful....
> Also, since we have option menus, will it be useful to have scrolled
> selection lists in addition? (Depends on how many things you think
> you want to put in a single set of options, I suppose...)
Incidentally, your option menus look great ... well, I guess and
option menu is an option menu, but it`s a trip to see one in an
HTML document!! As I say, some of our option menus got too big
(as in off-the-screen!), so we had to make them scrollable selection
lists. To tell the truth, I _think_ I would be just as happy with
a selection list in a separate document window, if that were
feasible ... i.e., if the inter-window communications weren't too
hairy. But it would also be real nice to have the selection list
widget adjust to the width of the selections so it doesn't take
so much screen space. That may be asking a bit much, though!
You're doing great.
Steve.
----- End Included Message -----