Prev: IE/FF XHR multi-file upload
Next: html form in javascript variable
From: Dr J R Stockton on 17 Nov 2009 11:26
In comp.lang.javascript message <03bae99e-3fe4-44cd-9fe7-39074ba0acf3(a)x6
g2000prc.googlegroups.com>, Mon, 16 Nov 2009 14:20:24, Terence
<tbwright(a)cantv.net> posted:
>
>WSH access is a term I have not met.
>

Windows Scripting Host. Covered in newsgroups
microsoft.public.scripting.jscript,
microsoft.public.scripting.vbscript,
microsoft.public.scripting.wsh.

Microsoft people have liked to use VBS in WSH to organise their
machines, but WSH also runs JS.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
From: Terence on 17 Nov 2009 16:34
On Nov 17, 9:38 pm, Stefan Weiss <krewech...(a)gmail.com> wrote:
>
> Your requirements are hard to understand, because you insist on using
> non-existent or misleading terms: "HTM", "java code" (JavaScript and
> Java are two very different languages), an "entity" called "this.form",
> and - again - something called a "Modzilla format".
> Your examples are incomplete and buggy, but when corrected, you say
> you're not interested in improving them. In short, you sound more like a
> customer than a fellow developer.

I'm NOT picking of Stefan, but using his observations to explain why
there is misunderstanding and wy I have to be choosy about a solution.


I am NOT a customer; I AM a developer and for 38 years, head of the
programming team of a 38-year running company. I myself use Fortran
and some types of ASM and am fairly expert in Fortran (I was IBM
Lecturer on its use at London University) and know several other
languages and assembler-type syntaxes, but I haven't a clue on, say,
java script. I repeat: the non-working code I posted to "solve" the
problem" which doesn't is NOT my code, but code e-mailed to me from
readers of this Forum.

Only the extract of a sample HTM form is actually our program-
generated coding.

Our software HAS to run in many operating system environments and DOS-
related file names have to have a suffix of three letters or less. So
we use 3 even in Windows. Hence my use of "HTM" when it may well be
XHTML or HTML. The conformation of the form syntax has to be relaxed
for the browsers "out there" and so has some deprecated code.

I already corrected my uninformed use of "Mo(d)zilla" to indicate it
was the specific encoding (URI) known loosely as "Mozilla" encoding -
and THAT seems to be true as a reference name used to be specific and
borne out by internet searches.

> > But .. (the form data and field lable) COULD be stored if there is a method of doing so. Which is what I'm looking for.
>
(Stefan:)
> There's no magic method like that. As I said before, you need to
>
>   a) serialize the form state, and
>   b) save the serialized string to a local text file
>
> In an earlier post, I have provided (b). What you're still missing is
> step (a), which if done correctly will produce your "Mozilla format".
> The form does not need to be submitted at all, so it doesn't matter if
> the method is set to POST or GET, or what its action is.
>
Agreed. Understood. But how? part b) I achieved, but it lacked the
field name each foeld content originated from, and the java scrpit was
specific to the form.

(snipped)

> Single byte characters? Brrr. A tool which supports multiple languages
> should really be Unicode capable, and use UTF-8 in HTML documents, or
> you're going to have a lot of fun with all the different character sets.

The trouble with step (a) WHICH I CAN DO in a specific form, is that
I want to have a fixed solution for any single-character form. (Note:
DOS environments, also supported by us, use 8-bit character sets. And
there are very few language sets (e.g. Chinese) that don't have a 256
character set table. WE DO handle Romaji, Cyrilic, Polish and Greek
for example. Since We don't care what language the documents were
written in: the computer used is set up for them! This has worked for
those 38 years!

> > Here is the smallest example of an expected RESULT file I could lay my lands on.
> > It shows the capture of binary radio and multiple button choices,
> > decimal values and text responses.
>
> When you're talking about form element types, it helps to use their
> correct names, instead of inventing new ones.

I disagree. The response DATA types I was referring to are known by
those names in the MR industry. You meant the underlying form field
types. But what I showed was the DATA, nor the form.

> > But the concept is to be able to use one solution to work on ANY htm
> > form, almost whatever the language set used, although we limit to left-
> > to-right single byte symbols.
>

> Since your HTML file is loaded from the local file system, there won't
> be any HTTP headers; you probably want to add a Content-Type <meta>
> element to your <head>.

As I said., the original form is used on a web-site, OR sent to a
selected respodee OR used for local data entry - all three modes . So
the form has to be capable of automatic modification (say by inclusion
at Line "x" of a java script function) to allow local storage in stead
of send out and back (as now) to the same workstation's e-mail attach
file. A tiny loading program can handle that for local use.

(shortend copy for reference)
> id=CUEST2++&01%2F03-00=+1&01%2F04-01=+1&01%2F04-02=+2&01%2F04-03=
> +3&01%2F04-04=+4&01%2F04-05=+5&01%2F05-00=+1&01%2F06-01=+1&01%2F06-02=
> +2&01%2F06-03=+3&01%2F06-05=+5&01%2F07-01=+1&01%2F07-03=+3&01%2F08-00=
> +1&01%2F09-01=+1&01%2F09-02=+2&01%2F10-00=+2&01%2F11-RR=

> I'm assuming Latin-1 for that one, because I'm human and happen to know
> Spanish and Latin-1, but how can the next tool in your chain of over 100
> programs know that? And what's with all the '+' characters? Don't you
> trim whitespace from your element values?

That coding is precisely what you get back from any browser
processing a form.
There IS NO WHITE SPACE in "Mozill" encoding. a "+" rplaces each
blank to avoid loss of whitespace; a %xx is a hex reprentation of a
punctuation and so on.

The cgi-equivalent processing tool expects the "universal" e-mailed
data format, so local data should be the same.


Sorry this has gone on long.
If somebody want to say "This is impossible, even working off-line
with a browser and with permission for storage, but Big Brother won't
let it happen", then do so.


>
> > The question, again, is, "how do I change the following htm code by
> > the use of java script, to replace the line
> >    <form method="post" name="STUDY999"
> > action="mailto:tbwri...(a)cantv.net">
> > with something that changes the action from e-mailing to one of
> > storing?"
>
> That's not the right question. No other form method or action will
> result in storing your file instead of sending it. You need to call a
> custom function on submit (or when the STORE button is clicked), which
> will then create the serialized and encoded string (a), and store it (b)
> locally. Form serialization is not hard, but there are a few gotchas. I
> don't have a stand-alone solution for you right now, but you should be
> able to find one on the web easily enough.
>
I TRIED.
(REALLY, Thanks Stefan)
From: Stefan Weiss on 18 Nov 2009 06:02
On 17/11/09 22:34, Terence wrote:
>> Single byte characters? Brrr. A tool which supports multiple languages
>> should really be Unicode capable, and use UTF-8 in HTML documents, or
>> you're going to have a lot of fun with all the different character sets.
>
> The trouble with step (a) WHICH I CAN DO in a specific form, is that
> I want to have a fixed solution for any single-character form. (Note:
> DOS environments, also supported by us, use 8-bit character sets. And
> there are very few language sets (e.g. Chinese) that don't have a 256
> character set table. WE DO handle Romaji, Cyrilic, Polish and Greek
> for example. Since We don't care what language the documents were
> written in: the computer used is set up for them! This has worked for
> those 38 years!

It's your call, of course, and I'm not saying 8-bit characters couldn't
work somehow, but Unicode is the standard and state-of-the-art for
multilingual systems, and has been for quite a while. DOS, on the other
hand, is a legacy system, and long past its end of life. You'll have
trouble finding a decent JavaScript enabled browser for DOS. All modern
operating systems support multibyte characters, as well as file names
which don't fit in 8+3 bytes.

You have a lot of experience in the IT field, and have been developing
software for longer than I have been breathing... I can only imagine the
broad array of systems and technology you have been working with over
the years, but with all due respect: even technical methods which have
worked for 38 years are not carved in stone. It may be time to
re-evaluate and update your requirements.

>> > But the concept is to be able to use one solution to work on ANY htm
>> > form, almost whatever the language set used, although we limit to left-
>> > to-right single byte symbols.
>
>> Since your HTML file is loaded from the local file system, there won't
>> be any HTTP headers; you probably want to add a Content-Type <meta>
>> element to your <head>.
>
> As I said., the original form is used on a web-site, OR sent to a
> selected respodee OR used for local data entry - all three modes.

I thought you said that the form was loaded from the local HD, I must
have missed the other two options. If the form is accessed over the
internet, additional permission/trust issues can arise - it may not be
possible to write to the local file system without modifying the user's
internet/zone options first. As to forms received by e-mail, those are
either saved to a local file, or script support will (hopefully) be
disabled in the mail client. A scenario which would give HTML content in
an e-mail the permissions to access the local file system would be a
recipe for disaster...

All in all, I agree that this really should be handled server-side.
There doesn't even have to be a local HTTP server, you could try
something as simple as this:

1) set the form action to http://yourserver/echo.cgi
2) the user fills out the form and POSTs it to your script
3) your echo.cgi script reads the POSTed contents (which is the URI-
encoded string format you described)
4) echo.cgi sets response HTTP header:
Content-Disposition: attachment; filename=filename.att
5) echo.cgi sends the string it read in step 3
6) user receives a file download and can chose where to store it

No client-side scripting would be required for this, and the echo script
would be 5-10 lines.

> (shortend copy for reference)
>> id=CUEST2++&01%2F03-00=+1&01%2F04-01=+1&01%2F04-02=+2&01%2F04-03=
>> +3&01%2F04-04=+4&01%2F04-05=+5&01%2F05-00=+1&01%2F06-01=+1&01%2F06-02=
>> +2&01%2F06-03=+3&01%2F06-05=+5&01%2F07-01=+1&01%2F07-03=+3&01%2F08-00=
>> +1&01%2F09-01=+1&01%2F09-02=+2&01%2F10-00=+2&01%2F11-RR=
>
>> I'm assuming Latin-1 for that one, because I'm human and happen to know
>> Spanish and Latin-1, but how can the next tool in your chain of over 100
>> programs know that? And what's with all the '+' characters? Don't you
>> trim whitespace from your element values?
>
> That coding is precisely what you get back from any browser
> processing a form.
> There IS NO WHITE SPACE in "Mozill" encoding. a "+" rplaces each
> blank to avoid loss of whitespace; a %xx is a hex reprentation of a
> punctuation and so on.

I know the format well enough. Since a "+" will (usually) be decoded
back to a space character, every field value in the string you posted
starts with a space (or maybe a "+"). I doubt this is intentional.

>> > The question, again, is, "how do I change the following htm code by
>> > the use of java script, to replace the line
>> > <form method="post" name="STUDY999"
>> > action="mailto:tbwri...(a)cantv.net">
>> > with something that changes the action from e-mailing to one of
>> > storing?"
>>
>> That's not the right question. No other form method or action will
>> result in storing your file instead of sending it. You need to call a
>> custom function on submit (or when the STORE button is clicked), which
>> will then create the serialized and encoded string (a), and store it (b)
>> locally. Form serialization is not hard, but there are a few gotchas. I
>> don't have a stand-alone solution for you right now, but you should be
>> able to find one on the web easily enough.
>>
> I TRIED.
> (REALLY, Thanks Stefan)

I get 150k results for "javascript serialize form" in Google.


cheers,
stefan
From: Terence on 20 Nov 2009 03:20
On Nov 18, 10:02 pm, Stefan Weiss <krewech...(a)gmail.com> wrote:
A VERY useful reply! Thank you.
I think we can persue this.

You are saying we find a simple web server which gets messages (data)
from the browser running locally, in on-line mode, and posting from a
form, but sending to the local in-house network. There, a cgi function
is handed the data script, which will then at least store the data
(and possibly be capable of returning a message requesting correct
field completions).

Note: used locally for data entry, the form IS loaded locally (or from
the local server, which is the same thing). Web-based and e-mailed
forms load as web forms or e-mailed local attachments respectively);
these DO originate via the web.

From there are cuurent systems can take over the data witout any
changes required.
I think the local form has to have the suffix HTA for local
permissions (maybe not)

(Relevant parts of Stefan's note below)

(There were no blanks in the original file posting; these are an
artifact of Google's display of long strings. Any code blank is coded
'+'; any text blank becomes %20 in the original coding.)
>
> I thought you said that the form was loaded from the local HD, I must
> have missed the other two options. If the form is accessed over the
> internet, additional permission/trust issues can arise - it may not be
> possible to write to the local file system without modifying the user's
> internet/zone options first. As to forms received by e-mail, those are
> either saved to a local file, or script support will (hopefully) be
> disabled in the mail client. A scenario which would give HTML content in
> an e-mail the permissions to access the local file system would be a
> recipe for disaster...

Actually that is what happens if you send a file NAMED study.HTA .
I tried Opera and IE on it, and it stores! On one machine the firewall
asked for permission the first time.
>
> All in all, I agree that this really should be handled server-side.
> There doesn't even have to be a local HTTP server, you could try
> something as simple as this:
>
> 1) set the form action tohttp://yourserver/echo.cgi
> 2) the user fills out the form and POSTs it to your script
> 3) your echo.cgi script reads the POSTed contents (which is the URI-
>    encoded string format you described)
> 4) echo.cgi sets response HTTP header:
>      Content-Disposition: attachment; filename=filename.att
> 5) echo.cgi sends the string it read in step 3
> 6) user receives a file download and can chose where to store it
>
> No client-side scripting would be required for this, and the echo script
> would be 5-10 lines.
>
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: IE/FF XHR multi-file upload
Next: html form in javascript variable