using a general browser as a form-based capture method
Terence
any process which will permit me to call a browser, while passing an
HTM form as a file name, in order to capture the entered data. The
calling opeartion is clear and works. OPera and Internat Explores, as
samples, do the job, but the storage so far achieved is only the ascii
contents of the fields and not filed-based coded replies and texts.
I then want to repeat the process with another input, the same form
and another stored output.
Of course, I know how to do the above reqirement with a web-based or
local-based form and using the POST mechanism to get one e-mailed
message per form entry to a (any specified) mailbox via a "Submit"-
type completion button.
Now, there are very many programs involved with the form generation
and the processing of the captured data, which currently relies on the
Modzilla form-generated and coded ascii e-mailed messages with the
attached data file. So changing one program or providing anothe is
possible, but is would not be possible to change all programs (>100).
I wish to do something similar to the working "POST and receive"
process, but wish to store the produced file (in the Modzilla coding)
on a local drive (the same cpu or local office net drives).
The following code processes the simple test form and writes the named
file, but only with the ascii contents of the text fields used. I need
radio, multiple, value and text fields and I need the filed-name
prefixes to each reply as per Modzilla coding.
How can I do this?
Can anyone offere a modified version of what is a basic satrt (below)?
<html>
<head>
<script language="javascript">
function Writedata()
{
var fso = new ActiveXObject("Scripting.FileSystemObject");
var write_id;
write_id = document.getElementById('write_id').value ;
var s = fso.CreateTextFile(write_id, true);
s.WriteLine(document.getElementById('name_id').value);
s.WriteLine(document.getElementById('id_id').value);
s.Close();
}
</script>
</head>
<body>
name : <input type="text" name="name" value="" id="name_id"><br/>
Address : <input type="text" name="id" value="" id="id_id"><br/>
Write file to : <input type="text" name="write" value="C://formdata//
filename.att" id="write_id"><br/>
<input type="button" onclick="Writedata(this.form)" value="STORE">
</body>
</html>
Terence
post!
Terence
> Sorry about the typos which seemed OK here (well, most) but not in the
> post!
I was rather hoping somebody can contribute to this question.
The browser must have the form data content in memory, plus the labels
and probably even a buffer with the proposed POST action text block.
All I wan to do is store this buffer (in Modzilla coded format) on a
local disk drive.
Stefan Weiss
> On Nov 12, 9:46 am, Terence <tbwri...@cantv.net> wrote:
>> Sorry about the typos which seemed OK here (well, most) but not in the
>> post!
>
> I was rather hoping somebody can contribute to this question.
I can only speak for myself, of course, but I found your problem
description kind of hard to read. That could explain the absence of
helpful replies. I'm still not sure if I understand the question
correctly, but it looks like you want to save a text file locally with
JavaScript from a Mozilla browser (Firefox?). That's possible, but not
with the ActiveX/FSO approach. I've added an example which should save
the file for you in Firefox and IE, assuming that access is granted.
You'll need to add error handling, form validation, and proper form
serialization if your form has radio buttons, select fields, etc.
Note that the file path is now "C:/formdata/filename.att" instead of
"C:/formdata/filename.att".
cheers,
stefan
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>File save test</title>
</head>
<body>
name : <input type="text" name="name" value="" id="name_id"><br>
Address : <input type="text" name="id" value="" id="id_id"><br>
Write file to : <input type="text" name="write"
value="C:/formdata/filename.att" id="write_id"><br>
<input type="button" onclick="saveFile()" value="STORE">
<script type="text/javascript">
function getVal (id)
{
return document.getElementById(id).value;
}
function getFilePath ()
{
// (snip validation)
return getVal("write_id");
}
function getFileData ()
{
// (snip validation)
var data = [];
data.push(getVal("name_id"));
data.push(getVal("id_id"));
return data.join("\r\n");
}
function saveFile ()
{
var path = getFilePath(),
data = getFileData();
if (typeof this.netscape == "object"
&& typeof netscape.security == "object") {
saveFile_Moz(path, data);
} else if (typeof this.ActiveXObject != "undefined") {
saveFile_ActiveX(path, data);
}
}
function saveFile_ActiveX (path, data)
{
var fso = new ActiveXObject("Scripting.FileSystemObject"),
file = fso.CreateTextFile(path, true);
file.Write(data);
file.Close();
}
function saveFile_Moz (path, data)
{
try {
netscape.security.PrivilegeManager
.enablePrivilege("UniversalXPConnect");
} catch (e) {
alert("Local file system access denied; aborting.");
return;
}
var cc = Components.classes,
ci = Components.interfaces,
file = cc["@mozilla.org/file/local;1"]
.createInstance(ci.nsILocalFile),
perms = parseInt("644", 8),
outStream;
file.initWithPath(path);
if (!file.exists()) {
file.create(ci.nsIFile.NORMAL_FILE_TYPE, perms);
}
outStream = cc["@mozilla.org/network/file-output-stream;1"]
.createInstance(ci.nsIFileOutputStream);
// ioFlags -1 indicates default mode:
// PR_WRONLY | PR_CREATE_FILE | PR_TRUNCATE
// see http://mxr.mozilla.org/mozilla-central/source/ (join)
// (join) netwerk/base/public/nsIFileStreams.idl#86
outStream.init(file, -1, perms, 0);
outStream.write(data, data.length);
outStream.close();
}
</script>
</body>
</html>
Stefan Weiss
> Note that the file path is now "C:/formdata/filename.att" instead of
"C://formdata//filename.att".
Thomas 'PointedEars' Lahn
Why? Are you confusing slashes and backslashes by any chance?
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)
Stefan Weiss
> Stefan Weiss wrote:
>
>> On 14/11/09 08:24, Stefan Weiss wrote:
>>> Note that the file path is now "C:/formdata/filename.att" instead of
>>
>> "C://formdata//filename.att".
>
> Why? Are you confusing slashes and backslashes by any chance?
No, the OP's example used '//' as path delimiter. I'm not familiar
enough with ActiveX to judge if there was any specific reason for that.
I changed it to a single forward slash, which appears to work well
enough with the ActiveX FileSystemObject and Mozilla's file API.
cheers,
stefan
Thomas 'PointedEars' Lahn
> On 14/11/09 10:29, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> On 14/11/09 08:24, Stefan Weiss wrote:
>>>> Note that the file path is now "C:/formdata/filename.att" instead of
>>> "C://formdata//filename.att".
>>
>> Why? Are you confusing slashes and backslashes by any chance?
>
> No, the OP's example used '//' as path delimiter. I'm not familiar
> enough with ActiveX to judge if there was any specific reason for that.
> I changed it to a single forward slash, which appears to work well
> enough with the ActiveX FileSystemObject and Mozilla's file API.
I see, a misunderstanding. I read your statement above and assumed you
introduced the double slashes because I could not find the path in the
source code at first.
However, both initWithPath() from XPCOM and CreateTextFile() from
ActiveX/COM require a file path. It is unlikely that on a WinDOS system
"C://formdata//filename.att" or "C:/formdata/filename.att" would be
recognized as such. It is more likely that the OP confused slashes and
backslashes in the first place, because "C:\\formdata\\filename.att"
evaluates to `C:\formdata\filename.att', which is a WinDOS file path.
I think your approach is too specialized, though. 3 stack levels for
retrieving the value of a single form control which name is hard-coded in
the third level?
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Stefan Weiss
> Stefan Weiss wrote:
>> On 14/11/09 10:29, Thomas 'PointedEars' Lahn wrote:
>>> Why? Are you confusing slashes and backslashes by any chance?
>>
>> No, the OP's example used '//' as path delimiter. I'm not familiar
>> enough with ActiveX to judge if there was any specific reason for that.
>> I changed it to a single forward slash, which appears to work well
>> enough with the ActiveX FileSystemObject and Mozilla's file API.
>
> I see, a misunderstanding. I read your statement above and assumed you
> introduced the double slashes because I could not find the path in the
> source code at first.
>
> However, both initWithPath() from XPCOM and CreateTextFile() from
> ActiveX/COM require a file path. It is unlikely that on a WinDOS system
> "C://formdata//filename.att" or "C:/formdata/filename.att" would be
> recognized as such.
Forward slashes are valid path separators in Windows. Sometimes
applications expect backslashes, but the system API and the FSO work
with forward slashes, too.
> I think your approach is too specialized, though. 3 stack levels for
> retrieving the value of a single form control which name is hard-coded in
> the third level?
You mean the |getFilePath| function? Yeah, that one isn't really
necessary. I could have read and validated the path in |saveFile|, but I
don't mind a little extra indirection for well defined tasks. In this
case it's especially useful, because we're writing to the local file
system, and bad things can happen if the path is incorrect*. Using a
separate function for this actually makes the code _less_ specialized,
IMHO: the script I used as a basis already had a getFilePath() method,
which combined the value from the text field with a BASE_PATH constant
(/home/username/tmp/). All I had to do was adjust |getFilePath|'s
implementation before I posted; the rest remained (more or less) unchanged.
The other "stack level" - the |getVal| function - is indeed unnecessary.
I only used it as a shortcut to keep the lines short enough. The
finished script will probably use the form's |elements| collection.
Terence's example even called |Writedata(this.form)| from the "STORE"
button, but there was no form, so I left that out.
cheers,
stefan
* This is somewhat mitigated by the fact that people are smart enough
not to run Windows as administrator. *cough*
Terence
I'll try again.
I have software than allows a user to take almost any document which
claims to be some form of questionnaire (in any roman-alphabet or
greek alphabet characters) and turns it into a valid web-based form
for a web-site or for e-mailing to selected persons (or as a response
to an e-mail).
The sotware also writes all the processing control files needed by
fixed programs, to statistically analyse the data, write reports and
cross-tab tables and frequency tables.
The software is compatible with several market research source code
systems and can use these variuos defining systems and stored data
formats, both ascii and binary.
The existing forms as generated, automatically send the collected data
back (BY E-MAIL), in the format used by all browsers that I have made
use of, referred to as "Modzilla format" by those who have
corresponded on the subject.
However, for in-house data entry, it would be very convenient to use
such a generated form to elicit data entry without input errors,
complete with the checks and branching controls included. All that is
needed, is to to change the ACTION=POST in the HTM to something else,
covered by the jave-coded "ON-CLICK" submit button control, to store
the same data locally on a local disc instead of sending as an
attached file to the web and getting it back from there. Obviously,
the Mdozilla-coded file is created; I just need to redirect it to
local storage.
Terence
system (or even several kinds of DOS and even DOS emulation on a
Macintosh). I used c:/directory/filename just as a common file example
for Windows or MSDOS systems (either forms '//' or '\\' actually work,
but some htm parsers seem to prefers a doubled slash to avoid code
confusion.
The processing system is currently Windows or MSDOS only, due to the
API-type services needed.
Thomas 'PointedEars' Lahn
> [...] I used c:/directory/filename just as a common file example
> for Windows or MSDOS systems (either forms '//' or '\\' actually work,
> but some htm parsers seem to prefers a doubled slash to avoid code
> confusion.
HTML has nothing to do with it. `//' is not a special markup sequence; it
is the prefix of ECMAScript-compliant single-line comments, but any markup
parser or script engine that recognizes it as such in a string literal is
FUBAR.
Terence
> I was rather hoping somebody can contribute to this question.
> The browser must have the form data content in memory, plus the labels
> and probably even a buffer with the proposed POST action text block.
> All I wan to do is store this buffer (in Modzilla coded format) on a
> local disk drive.
I have been requested to post more detail.
I am aware that for personal security reasons, browsers do not
normally write to disc without going through an approved download
process. But what if the browser is working OFFLINE? What happens to
the form data? Are there then the same restrictions in force?
I have computers that are never connected to any network, yet I use
them for form generation and even web-site code testing via any (a
few, precisely for testing) browsers.
It has been suggested that the problem can (theoretically) be resolved
by using something like TinyWeb on the same computer, so that the form
posts to "localhost" and the web-server on the same computer (each and
every one needed, else one local network server) then creates the
usual dummy message and attaches the Modzilla coding of data contents
(ALL browsers that process code seem to support the format) and sends
the dummy message to the local web server.
Then the web server takes the message and attached needed file and
puts it in a local mailbox, which is also on the same computer..
Now, Tinyweb is a server program, with still huge resources and
features, including a cgi processor (which implies it could process
the form and send back error signals to the user....).
This all seems to be a huge sledgehammer to crack a mustard seed.
Since the browser must have the data from the Form in a buffer, (in
order to create the message and attachment) all I need to do, is to
get the action method="POST" to be modified to "simply" store the same
buffer on disc. Even if it only works in OFFLINE mode.
I have tested variations on the suggested (simple example) code below,
that does some of this, but only stores the unlabled ascii-string
contents of the fields filled ( think, from the WriteLine statements
instead of ALL the form used), so (even if this was accepatable).
Only my firewall asked if I wanted to store, and only the once.
I have no idea of which fields they were and the post-processing is
useless..
Remember, my object is to take any standard form HTM coding and insert
(actually generate) a modified action section to allow this target
operation. The result is a automated flexible general purpose data
entry system (since I have the "after-posting and receiving" part of
the form data processing already, that matches the original form
generation from the original enquiring any-format document).
<html>
<head>
<script language="javascript">
function Writedata()
{
var fso = new ActiveXObject("Scripting.FileSystemObject");
var write_id;
write_id = document.getElementById('write_id').value ;
var s = fso.CreateTextFile(write_id, true);
s.WriteLine(document.getElementById('name_id').value);
s.WriteLine(document.getElementById('id_id').value);
s.Close();
}
</script>
</head>
<body>
name : <input type="text" name="name" value="" id="name_id"><br/>
Address : <input type="text" name="id" value="" id="id_id"><br/>
Write file to : <input type="text" name="write" value="c:/formdata/
filename.att" id="write_id"><br/>
<input type="button" onclick="Writedata(this.form)" value="STORE">
</body>
</html>
And this is the structure of a typical form (id STUDY999) generation
for such use, which will work offline, but reminds the user to get on-
line again to send the data in the current "there-and-back" mode of
use:-
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//
EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html><head><title>STUDY999</title></
head>
<form method="post" name="STUDY999"
action="mailto:tbwr...@cantv.net">
<input type="hidden" name="id"
value="STUDY999">
<table width=100% border=0
bgcolor="#C0C0FF"><tr><td>
<font color="#000000"
size="+1">
[any
form]
</font></td></tr></
table>
<hr><table cellspacing=0
cellpadding=0>
<tr><td><font color="#000000" size=
+1>
Connect to the Internet for normal e-mailing, then click on <br>
"Submit";
after which you can disconnect if you wish.</td></
tr>
<tr><td
align="center">
<input type="submit"
value="Submit">
</td></tr></table></form></body></
html>
Result:-
In Modzilla format, the first string of the coding in the data file
is id=STUDY999.:-
id=STUDY999++&01%2F03-00=+1&01%2F04-01=+1&01%2F04-02=+2&01%2F04-03=+3
etc
Thomas 'PointedEars' Lahn
> On Nov 14, 1:17 pm, Terence <tbwri...@cantv.net> wrote:
>> I was rather hoping somebody can contribute to this question.
>> The browser must have the form data content in memory, plus the labels
>> and probably even a buffer with the proposed POST action text block.
>> All I wan to do is store this buffer (in Modzilla coded format) on a
>> local disk drive.
>
> I have been requested to post more detail.
>
> I am aware that for personal security reasons, browsers do not
> normally write to disc without going through an approved download
> process. But what if the browser is working OFFLINE?
Doesn't matter.
> What happens to the form data?
The same as if you were "online".
> Are there then the same restrictions in force?
Yes, as long as you are not working in a privileged environment.
> I have computers that are never connected to any network, yet I use
> them for form generation and even web-site code testing via any (a
> few, precisely for testing) browsers.
>
> It has been suggested that the problem can (theoretically) be resolved
> by using something like TinyWeb on the same computer,
I would use Apache, but it is all the same to the Web browser. It does not
care that the host name is `localhost'.
> Since the browser must have the data from the Form in a buffer, (in
> order to create the message and attachment) all I need to do, is to
> get the action method="POST" to be modified to "simply" store the same
> buffer on disc. Even if it only works in OFFLINE mode.
It does not work this way. An HTML form is designed to make HTTP requests.
> Remember, my object is to take any standard form HTM coding and insert
_objective_?
> (actually generate) a modified action section to allow this target
> operation.
Parse error.
> The result is a automated flexible general purpose data
> entry system (since I have the "after-posting and receiving" part of
> the form data processing already, that matches the original form
> generation from the original enquiring any-format document).
>
> <html>
> <head>
> <script language="javascript">
Your markup is not Valid. <http://validator.w3.org/>
> function Writedata()
The identifier should start lowercase.
> {
> var fso = new ActiveXObject("Scripting.FileSystemObject");
> var write_id;
> write_id = document.getElementById('write_id').value ;
You can initialize the variable in the same statement (as above).
> var s = fso.CreateTextFile(write_id, true);
> s.WriteLine(document.getElementById('name_id').value);
> s.WriteLine(document.getElementById('id_id').value);
You could save three calls to document.getElementById() if you used the form
object reference that you are already passing to WriteData(), which should
be writeData(). For example:
function writeData(f)
{
// ...
var s = fso.CreateTextFile(f.elements["write_id"].value, true);
if (s)
{
s.WriteLine(f.elements['name_id'].value);
s.WriteLine(f.elements['id_id'].value);
}
// ...
}
> s.Close();
> }
>
> </script>
> </head>
> <body>
> name : <input type="text" name="name" value="" id="name_id"><br/>
Not Valid. <br/> is XHTML, not HTML.
> Address : <input type="text" name="id" value="" id="id_id"><br/>
`name' and `id' are two particularly bad names because it creates problems
when accessing the corresponding form controls (or the form name or ID).
> Write file to : <input type="text" name="write" value="c:/formdata/
> filename.att" id="write_id"><br/>
`write' is not a very wise name for this either. And use a TABLE here
instead.
> <input type="button" onclick="Writedata(this.form)" value="STORE">
It should be obvious that `this.form' does not work without a FORM element.
> </body>
> </html>
>
> And this is the structure of a typical form (id STUDY999) generation
> for such use, which will work offline,
Maybe on your machine.
> but reminds the user to get on-line again to send the data in the current
> "there-and-back" mode of use:-
Parse error.
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//
> EN"
> "http://www.w3.org/TR/html4/loose.dtd">
What you declare is not what you write below, and vice-versa.
> <html><head><title>STUDY999</title></
> head>
This error is due to a Google Groups bug, I suppose.
> <form method="post" name="STUDY999"
> action="mailto:tbwr...@cantv.net">
`mailto:' with forms has never worked reliably. Forget it. And
method="POST" does not make any sense without a HTTP server.
> <input type="hidden" name="id"
> value="STUDY999">
> <table width=100% border=0
> bgcolor="#C0C0FF"><tr><td>
There are required quotes missing around `100%', recommended quotes missing
around `0', and the `bgcolor' attribute has been deprecated in favor of CSS
more than 11 years ago.
> <font color="#000000"
> size="+1">
>
> [any
> form]
>
> </font>
FORM is a block-level element, it must not be contained in an inline element
like FONT. FONT has been deprecated in favor of CSS (`font-'*, `background-
*', and `color' properties) more than 11 years ago anyway. The rest of your
markup is awfully invalid, too.
> [...]
> Result:-
> In Modzilla format, the first string of the coding in the data file
Cannot parse "Modzilla format". There is no data file. There is an e-mail
message at most.
> is id=STUDY999.:-
I do not think this is an exact representation of any data related to this
code.
> id=STUDY999++&01%2F03-00=+1&01%2F04-01=+1&01%2F04-02=+2&01%2F04-03=+3
Looks like percent-encoding according to RFC 3986 which is what can be
expected from an HTTP (RFC 1945/2616) POST request but does not fit RFC
2822, of course.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
captain...@gmail.com
This is highly confusing. You are talking about a web server listening
on localhost, receiving an html form posted from a browser on the same
machine, and then e-mailing the form data back to a user on the same
local machine ?
Why would you want the server to e-mail the encoded form data back to
a user on the same , rather than act on it directly and send the
result back to the browser ?
captain...@gmail.com
>
> > I was rather hoping somebody can contribute to this question.
> > The browser must have the form data content in memory, plus the labels
> > and probably even a buffer with the proposed POST action text block.
> > All I wan to do is store this buffer (in Modzilla coded format) on a
> > local disk drive.
>
> I have been requested to post more detail.
>
> I am aware that for personal security reasons, browsers do not
> normally write to disc without going through an approved download
> process. But what if the browser is working OFFLINE? What happens to
> the form data? Are there then the same restrictions in force?
>
> I have computers that are never connected to any network, yet I use
> them for form generation and even web-site code testing via any (a
> few, precisely for testing) browsers.
>
> It has been suggested that the problem can (theoretically) be resolved
> by using something like TinyWeb on the same computer, so that the form
> posts to "localhost" and the web-server on the same computer (each and
> every one needed, else one local network server) then creates the
> usual dummy message and attaches the Modzilla coding of data contents
> (ALL browsers that process code seem to support the format) and sends
> the dummy message to the local web server.
>
> Then the web server takes the message and attached needed file and
> puts it in a local mailbox, which is also on the same computer..
>
"Modzilla coding" The term you seek is most likely url encoded. I
forgot to ask what happens when the user receives the encoded form
data by email ? I presume he/she copies and pastes the encoded string
into another program for processing ?
Dr J R Stockton
g2000pra.googlegroups.com>, Sun, 15 Nov 2009 14:36:03, Terence
<tbwr...@cantv.net> posted:
>
>I am aware that for personal security reasons, browsers do not
>normally write to disc without going through an approved download
>process.
AIUI, if you make an HTA page, using MSIE, you can combine Web-style
appearance with WSH-style access to the machine. And you can distribute
it by the Web mechanism, with instructions to save to local disc. I
have not tried it.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Terence
Thomas Lahn has criticised, not "my" code" but the acumulation of code
offered by others after many concecutive insertions and fixes.
NONE of it is "my" code"! All shown except that below was in posting
responses.
Of course it doesn't match, and is a mis-mush and of incorrect syntax.
I'm not all that interested in correcting the code of others, I'm just
interested in find out what java code is necessary to take the pure
HTM form data ( the entity "this.form" for example) and store the
user-input data on the local disc in Modzilla format.
A REAL HTM form generated by our system is totally correct and woks
fine to send data needlessly back-and-forth over the internet to get
the form Modzill data back.
And, I point out, if your browser is working offline and you fill in
an htm form, that captured form data isn't going anywhere if the
action method is POST.
But it COULD be stored if there is a method of doing so. Which is what
I'm looking for.
A typical source file in HTM for our purposes would be about 40k to
100k; each form output would be about 2-4k of data per person.
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. This one happens to contain spanish
responses. Greek wouldn't show up very well here.
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.
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=
+1.+Cumplimiento+de+acuerdos+ANS+%28actualizaci%F3n%2C+calidad+de+la
+data%2C+tiempo+de+respuesta%29%0D%0A+2.+Gesti%F3n+y+atenci%F3n+de+los
+Ejecutivos+de+Cuenta%0D%0A+3.+Proactividad+en+Proyectos+
%A0&01%2F16-00=+2&01%2F17-00=+2&01%2F18-00=+3&01%2F19-00=+5&01%2F20-00=
+5&01%2F21-00=+3&01%2F22-00=+3&01%2F23-00=+4&01%2F24-00=+3&01%2F25-00=
+3&01%2F27-00=+4&01%2F28-00=+4&01%2F29-00=+5&01%2F30-00=+3&01%2F31-00=
+4&01%2F32-00=+5&01%2F33-00=+5&01%2F34-00=+4&01%2F35-00=+5&01%2F36-00=
+4&01%2F37-00=+5&01%2F38-00=+4&01%2F39-02=+2&01%2F40-09=+9&01%2F41-03=
+3&01%2F42-02=+2&01%2F43-00=+1&01%2F44-00=+6&01%2F45-05=+5&01%2F46-02=
+2&01%2F47-RR=+%A0Banco+de+Venezuela&01%2F49-RR=+%A0VPA+Riesgos+de
+Particulares&01%2F51-RR=+%A0VPE+Riesgos&01%2F53-00=+4&01%2F54-00=+1.
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...@cantv.net">
with something that changes the action from e-mailing to one of
storing?"
Obviously the final line referring to the Internate and the button
"submit" would become an action of "STORE" and an early extra input
field would have captured the person ID to create a file name variable
for storing the data.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head><title>STUDY999</title></head>
<form method="post" name="STUDY999"
action="mailto:tbwri...@cantv.net">
<input type="hidden" name="id" value="STUDY999">
<table width=100% border=0 bgcolor="#C0C0FF"><tr><td>
<font color="#000000" size="+1">
[any form]
</font></td></tr></table>
<hr><table cellspacing=0 cellpadding=0><tr><td><font color="#000000"
size= +1>
Terence
> This is highly confusing. You are talking about a web server listening
> on localhost, receiving an html form posted from a browser on the same
> machine, and then e-mailing the form data back to a user on the same
> local machine ?
YES. Without solving local storage, this is how it has to work; else a
LOCAL webserver for the same purpose. That was the suggesting of a
private respose suggesting the use of a local webserver to acheive the
same objective. As I said "sledgehammer".
>
> Why would you want the server to e-mail the encoded form data back to
> a user on the same , rather than act on it directly and send the
> result back to the browser ?
Note: the "user" is one person doing data entry (from a paper near-
identical form) on a form ALSO used on the internet. The same person
may use different forms on the same day. One single processing system
has to process all forms of similar input the same way. There is NO
cgi-based validation necessary. The data from the forms is self-
identifying from the first form-name field.
Right now, to do data input repeatedly with a single particular form,
each workstation sends the data to the internet as a mailto: message
attachment (POST) and the data comes right back to the same location
as file of Modzilla coding (which format is needed). It is totally
sufficient in these cases fo the HTM form logic to collect acceptable
data. Any between-questions logical inconsistences are resolved (after
automatic detection and attention drawing) by inspection of the paper
document during a detect-and-correct process that is very rarely
needed.
Terence
<captainkirk1...@gmail.com> wrote:
> "Modzilla coding" The term you seek is most likely url encoded. I
> forgot to ask what happens when the user receives the encoded form
> data by email ? I presume he/she copies and pastes the encoded string
> into another program for processing ?
The Modzilla coding is automatically parsed, the data extracted and
compared with generated expected limit values and internal logic,
field labels supplied, a data set entry for that surveyed person is
inserted in the data base. Any text reponses are parsed via the
appropriate language tool and multiply coded as furthe data. The data
base is logically analysed and cross-checked: any individual
discrepencies detectd and correction called for by instection of the
original paper document.
Then automatic processing by programs under the control of control
files themselves generated from the the original questionnaire form
analyse the entire data base and write complex statistical reports
with confidence levels in RTF format (and other) for presentations.
Terence
>
> AIUI, if you make an HTA page, using MSIE, you can combine Web-style
> appearance with WSH-style access to the machine. And you can distribute
> it by the Web mechanism, with instructions to save to local disc. I
> have not tried it.
>
> --
I agree John, I should have said that the form name used becomes .HTA
for this purpose.
This achieved some small succes but not the Modzilla coding and not as
a general for all elements output.
But what else is needed to store data locally (see repeatsd code
extraction earlier)?
I don't want to distribute forms with instructions to fill and store
on the local disc (although we Do distribute to individual, whose
browser automatically MAIL the data by the POST method to US, where
it is processed. And on-web-site forms for non-pre-selected users, do
the same action).
All the forms filled in are on ONE machine and the data to be stored
on ONE machine (conceptually - really there are 15 or so). I want to
avoid mailing to ourselves, which seems ridiculous waste of energy and
web traffic.
WSH access is a term I have not met.
Terence
1) "Modzilla" should be Mozilla. I accepted some elses typo as the
correct spelling and reference.
2)" Mozilla coding" IS URL-coding as noted by "CaptainKirk1966".
So I'm after URL code, stored locally, as the output of the form.
This may be terribly obvious to some, bu all my HTMx reference books I
have assume only method=POST e-mailing in URL or other-site cgi-
checked will be used.
Terence
OOPs (again)! URI coding!
In essance I'm try to find a way to define a local file name as an
agent for processing.
Suggestion: Is there a way to SAVE the filled-in FORM as a file on
disc?.
This would probaly be a list of field names, indexes, and contents.
Evertjan.
> Oh dear!
[..]
> I'm not all that interested in correcting the code of others, I'm just
> interested in find out what java code is necessary to take the pure
> HTM form data ( the entity "this.form" for example) and store the
> user-input data on the local disc in Modzilla format.
Java code being OT on this NG,
and moreover this NG being not interested in what you find not interesting,
and you not quoting your responses,
please dear Terence,
concider no more using this NG.
Modzilla?
Not a format,
perhaps a kind of cheese prefered in the new world?
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Stefan Weiss
> I'm not all that interested in correcting the code of others, I'm just
> interested in find out what java code is necessary to take the pure
> HTM form data ( the entity "this.form" for example) and store the
> user-input data on the local disc in Modzilla format.
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.
> A REAL HTM form generated by our system is totally correct and woks
> fine to send data needlessly back-and-forth over the internet to get
> the form Modzill data back.
> And, I point out, if your browser is working offline and you fill in
> an htm form, that captured form data isn't going anywhere if the
> action method is POST.
> But it COULD be stored if there is a method of doing so. Which is what
> I'm looking for.
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 "Modzilla 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.
> 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.
> This one happens to contain spanish
> responses. Greek wouldn't show up very well here.
> 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.
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.
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>.
> 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=
> +1.+Cumplimiento+de+acuerdos+ANS+%28actualizaci%F3n%2C+calidad+de+la
> +data%2C+tiempo+de+respuesta%29%0D%0A+2.+Gesti%F3n+y+atenci%F3n+de+los
> +Ejecutivos+de+Cuenta%0D%0A+3.+Proactividad+en+Proyectos+
> %A0&01%2F16-00=+2&01%2F17-00=+2&01%2F18-00=+3&01%2F19-00=+5&01%2F20-00=
> +5&01%2F21-00=+3&01%2F22-00=+3&01%2F23-00=+4&01%2F24-00=+3&01%2F25-00=
> +3&01%2F27-00=+4&01%2F28-00=+4&01%2F29-00=+5&01%2F30-00=+3&01%2F31-00=
> +4&01%2F32-00=+5&01%2F33-00=+5&01%2F34-00=+4&01%2F35-00=+5&01%2F36-00=
> +4&01%2F37-00=+5&01%2F38-00=+4&01%2F39-02=+2&01%2F40-09=+9&01%2F41-03=
> +3&01%2F42-02=+2&01%2F43-00=+1&01%2F44-00=+6&01%2F45-05=+5&01%2F46-02=
> +2&01%2F47-RR=+%A0Banco+de+Venezuela&01%2F49-RR=+%A0VPA+Riesgos+de
> +Particulares&01%2F51-RR=+%A0VPE+Riesgos&01%2F53-00=+4&01%2F54-00=+1.
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?
> 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...@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.
cheers,
stefan
Dr J R Stockton
g2000prc.googlegroups.com>, Mon, 16 Nov 2009 14:20:24, Terence
<tbwr...@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.
Terence
>
> 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...@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)
Stefan Weiss
>> 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...@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
Terence
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