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.
(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!
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.
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.
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)
