From: Terence on
I should have noted that the user system for data entry is any Windows
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.
From: Thomas 'PointedEars' Lahn on
Terence wrote:

> [...] 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.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: Terence on
On Nov 14, 1:17 pm, Terence <tbwri...(a)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? 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:tbwright(a)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



From: Thomas 'PointedEars' Lahn on
Terence wrote:

> On Nov 14, 1:17 pm, Terence <tbwri...(a)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:tbwright(a)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
From: CaptainKirk1966 on
On Nov 15, 5:36 pm, Terence <tbwri...(a)cantv.net> wrote:
> On Nov 14, 1:17 pm, Terence <tbwri...(a)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? 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 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 ?