Yes, that's what we should do but I NEED A HACK NOW because I have to do my work.
My boss sits behind my neck :-) (that was English for Runaways, wasn't it?).
So my priority NOW is to do it (tricky) NOW - but of course I am interested
in solving the problem generally. So what's up with saying
<form method=GET EXECUTIONPOINT=LOCAL href="file://localhost/THEDIR/theprog">
which means that the only possible execution place ("file://") IS AT YOUR OWN SIDE
protecting from abuse by third (second?) parties?.
IF there is no EXECUTIONPOINT, the standard "misbehaviour"
works fine and all will be done exactly as now, and all is ok!
(too blue-eyed???)
> 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
So this would be like
'<form method=LOCALPOST href="HTTP://localhost/THEDIR/MYSCRIPT">'
??? (can you show a full explained, real working environment?)
>
> 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
(I don't have a server at laptop-side...but I know, it's general)
> - 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 ?
I have to try it...
> Does anyone know which of the new flavours of HTML plan to
> solve this type of problem or not as the case may be ?
I forgot it, sorry!
Cheers Frank