Yes fine, but your's is only one instance of a number of types
of situations where local form processing is needed. Why don't
we look at a generic solution rather than discussing a quick hack for
your problem ?
>>> One of our new products has a well known browser(dare I say it... Mosaic)
>>> built into it as help engine/WWW navigator. We needed this local
>>> form processing capability. So we have restricted this to only
>>> allow calls to 'safe' binaries shipped with the products.
>>
>>HOW?
>>
See above. If you are really desparate then here goes...
invent a new method e.g. LOCALPOST
in the submit button callback, verify that you want LOCALPOST
Call your local processing stuff for this case
Again I do not recommend this. We need to standardize on an
agreed general solution.
If we have local (doc side) scripting
- you can still access all your files from your server
- process them as need be with your scripting language
- create 'on the fly' docs with your scripting language
If you actually want to execute a process on the client side that
is specified by what is written in a document then the system is
open for abuse and you base your model on that of trust.
How many sites are going to go for that ??
Can your processing not be done within the document via the scheme
proposed ?
Does anyone know which of the new flavours of HTML plan to
solve this type of problem or not as the case may be ?
--_ __ __ _ __________________________________________________________ | |\ / /| | Guy Singh IXI Limited Email: guy@x.co.uk | | / / | | Development Vision Park Tel : +44 223 236555 |_|/_/_\|_| Cambridge UK FAX : +44 223 236466