how to capture locally, the data content of an HTM form?

[Terence]

I tried finding a solution on the Google Group Javsscript Forum java.
I am now posting here.

1) we have working systems of programs that used locally, use HTM
forms to cature data and send e-mail messages out-and-back
(unnecessarily?) to match use of the SAME input form in remote and web
locations and situations. Some paper versions of the same forms are
read by fast automatic machines; other similar, but not printed so
geometrically exact, are
data-input by hand. It is these that I am trying to find a solution
for by using a form to
capture data locally, by seekeing to store the output onf the user's
browser, to a local disk.

Here is a very small extract of the type of data which we know as
"Mozilla" format, which we need to use. Any correction of this term
used by me would be appreciated. This shows the coded result of the
capture of binary radio and multiple button choices, There would also
be decimal values and text responses.

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= ....

2) we need a single solution that fits every form we generate (single-
character alphabets);
and we could upgrade by removing obsoleted and some deprecated HTM
tags still in use.

3) whatever is written locally, if not "Mozilla" encoding, has be a
string of ascii text strings and the field identifying label and its
index (e.g. selected button values).So that
the "Mozilla" coding can be generated for the existing processing
systems.

5) any solution (e.g. java scripting) used must be fixed, not varying
with the form used.

The original form is used on a web-site, OR sent to a selected
respondee 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 instead of send
out-and-back (as now) to the same workstation's e-mail attach file. (A
tiny loading program
couldn handle that for local use).

The cgi-equivalent processing for input correction is NOT
neccessary. but a local cgi
solution could be contemplated as long as the "Mozilla" format is
generated.
(The final processing tool expects the "universal" e-mailed data
format, so local data should
produce the same data files).

Existing forms include the initial structure:-
   <form method="post" name="STUDY999" action="mailto:
(emailaddress)">
and so need something that changes the action from e-mailing to one of
storing locally.on the usual "submit" button action.

An alternative could be the SAVING of each form and data, so that data
extraction could occur from these files.

 

[Raymond Schmit]

<form method="post" name="STUDY999" action="mailto:
(emailaddress)">

This coding doesnot work if the user didi not use microsoft product
for surfing or mailing.

 

[Adrienne Boswell]

Gazing into my crystal ball I observed Terence <[email protected]>
writing in

I tried finding a solution on the Google Group Javsscript Forum java.
I am now posting here.

1) we have working systems of programs that used locally, use HTM
forms to cature data and send e-mail messages out-and-back
(unnecessarily?) to match use of the SAME input form in remote and web
locations and situations. Some paper versions of the same forms are
read by fast automatic machines; other similar, but not printed so
geometrically exact, are
data-input by hand. It is these that I am trying to find a solution
for by using a form to
capture data locally, by seekeing to store the output onf the user's
browser, to a local disk.

Here is a very small extract of the type of data which we know as
"Mozilla" format, which we need to use. Any correction of this term
used by me would be appreciated. This shows the coded result of the
capture of binary radio and multiple button choices, There would also
be decimal values and text responses.

+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= ....

2) we need a single solution that fits every form we generate
(single-
character alphabets);
and we could upgrade by removing obsoleted and some deprecated HTM
tags still in use.

3) whatever is written locally, if not "Mozilla" encoding, has be a
string of ascii text strings and the field identifying label and its
index (e.g. selected button values).So that
the "Mozilla" coding can be generated for the existing processing
systems.

5) any solution (e.g. java scripting) used must be fixed, not varying
with the form used.

The original form is used on a web-site, OR sent to a selected
respondee 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 instead of send
out-and-back (as now) to the same workstation's e-mail attach file. (A
tiny loading program
couldn handle that for local use).

The cgi-equivalent processing for input correction is NOT
neccessary. but a local cgi
solution could be contemplated as long as the "Mozilla" format is
generated.
(The final processing tool expects the "universal" e-mailed data
format, so local data should
produce the same data files).

Existing forms include the initial structure:-
   <form method="post" name="STUDY999" action="mailto:
(emailaddress)">
and so need something that changes the action from e-mailing to one of
storing locally.on the usual "submit" button action.

An alternative could be the SAVING of each form and data, so that data
extraction could occur from these files.

You need to do this server side, and either email the responses to the
responsible party and/or store them in a database.

I recommend having the forms post to themselves, it's a lot easier in
the long run.

Don't use a mailto as an action, as you can see that is fraught with
danger, and there is no way to check the input before it goes off to
whomever - who knows what you might get from a client?

See http://www.cs.tut.fi/~jkorpela/forms/ and
http://www.isolani.co.uk/articles/mailto.html for more information.

 

[Terence]

Gazing into my crystal ball I observed Terence <[email protected]>
writing in














You need to do this server side, and either email the responses to the
responsible party and/or store them in a database.

I recommend having the forms post to themselves, it's a lot easier in
the long run.

Don't use a mailto as an action, as you can see that is fraught with
danger, and there is no way to check the input before it goes off to
whomever - who knows what you might get from a client?

Seehttp://www.cs.tut.fi/~jkorpela/forms/andhttp://www.isolani.co.uk/articles/mailto.htmlfor more information.

a) We already use posting via the web to get the same dummy message
back in an e-mail box, but this action stories the attached data file
(succeful form field contents) in the "attach" folder. This of course
is the easy way, but uses the internet to write form data from a
computer to the very same computer. You would think there would be a
legal method if the browser was running off-line on a local form!
(Repeatedly, you call the browser and pass the form name; this works;
the sotored files automatiacll get a sequnce number to the root name).

b) since the "mailto" address is us, and we are on our local commecial
server, it comes back safely.
Anyway the 'Mozilla' encoding is less understandable than Greek, (and
we use Greek). Nobody would know what was asked and what was answered;
the form is not sent; only the field data

c) the best advice yet, from Stefan Weiss is:

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.

(But this requiers a to-and-fro form a LOCAL server, instead of a WEB
server)!


d) Is there a way of SAVING the form's current contents (as if the
operator had to take a break)?
This would achieve the purpose!

 

[Adrienne Boswell]

Gazing into my crystal ball I observed Terence <[email protected]>
writing in

les/mailto.htmlfor more information.


a) We already use posting via the web to get the same dummy message
back in an e-mail box, but this action stories the attached data file
(succeful form field contents) in the "attach" folder. This of course
is the easy way, but uses the internet to write form data from a
computer to the very same computer. You would think there would be a
legal method if the browser was running off-line on a local form!
(Repeatedly, you call the browser and pass the form name; this works;
the sotored files automatiacll get a sequnce number to the root name).

b) since the "mailto" address is us, and we are on our local commecial
server, it comes back safely.
Anyway the 'Mozilla' encoding is less understandable than Greek, (and
we use Greek). Nobody would know what was asked and what was answered;
the form is not sent; only the field data

You don't understand do you? The mailto action is not recommended
simply because it is unreliable. There is nothing you can do server
side to check the data coming in - yes you can use javascript, but if
the client does not have javascript enabled, or does and sends you
malicious data, the mailto can do nothing about it, except send the
malicious data.

c) the best advice yet, from Stefan Weiss is:


(But this requiers a to-and-fro form a LOCAL server, instead of a WEB
server)!


d) Is there a way of SAVING the form's current contents (as if the
operator had to take a break)?
This would achieve the purpose!

Do it server side and send the responses to a database.

 

[Jan C. Faerber]

It is these that I am trying to find a solution
for by using a form to
capture data locally, by seekeing to store the output onf the user's
browser, to  a local disk.

here they try to achieve it with cookies:
http://bytes.com/topic/php/answers/4402-save-html-forms-data-local-disk

An alternative could be the SAVING of each form and data, so that data
extraction could occur from these files.

or php or java?
i don't know the solution in php but
with java I think you have 'versatile' (not public, protected, ...)
for LAN purpose.

that's it from now

 

[Terence]

Adrienne Boswell said:-

You don't understand do you?  The mailto action is not recommended
simply because it is unreliable.  There is nothing you can do server
side to check the data coming in - yes you can use javascript, but if
the client does not have javascript enabled, or does and sends you
malicious data, the mailto can do nothing about it, except send the
malicious data.

No, Adrianne, YOU don't get it. I described the operations quite
completely. And we don't use scripting offsite.
There IS no server side other than the local e-mail service. There is
no cgi-bin program sitting somewhere and checking the form data
offsite, because whatever comes back to the e-mail box gets processed
locally (almost) immediately. I.E. the content is checked on-site and
either matches the expected internal consistency, and is accepted or
doesn't and is not further processed. The form logic handles all the
important decision requirements; the form field data type handles the
content format; text is parsed by a language processor for
interpretation of information content; that's enough for us.

So data from a remote (known) person come into the e-mail box (no
website processing), while for the use of the same form for local
data input (paper interviews or similar or CAPI), we currently go out-
and-back to the same e-mail box. Which is why we are looking for a
method of storing on the same data-input computer.

"Malicious data" is very unlikely because, should it occur, it's easly
noted and we know the supplier and can take any action we want.

 

[Terence]

here they try to achieve it with cookies:http://bytes.com/topic/php/answers/4402-save-html-forms-data-local-disk


or php or java?
i don't know the solution in php but
with java I think you have 'versatile' (not public, protected, ...)
for LAN purpose.

that's it from now

Thanks Jan. Wa interesting 2005 forum exchange.

 

[Terence]

And while on the subject of cookies:-
I couldn't sign into this Google Groups Forum (ONLY, of all the 10
or so I contribute to or learn from), because it uses ANOTHER cookie
unrelated to "the site I am visiting". Seems to be new this week!
Found how to fix that one...

 

[Jonathan N. Little]

Adrienne Boswell said:-


No, Adrianne, YOU don't get it. I described the operations quite
completely. And we don't use scripting offsite.
There IS no server side other than the local e-mail service. There is
no cgi-bin program sitting somewhere and checking the form data
offsite, because whatever comes back to the e-mail box gets processed
locally (almost) immediately. I.E. the content is checked on-site and
either matches the expected internal consistency, and is accepted or
doesn't and is not further processed. The form logic handles all the
important decision requirements; the form field data type handles the
content format; text is parsed by a language processor for
interpretation of information content; that's enough for us.

So data from a remote (known) person come into the e-mail box (no
website processing), while for the use of the same form for local
data input (paper interviews or similar or CAPI), we currently go out-
and-back to the same e-mail box. Which is why we are looking for a
method of storing on the same data-input computer.

"Malicious data" is very unlikely because, should it occur, it's easly
noted and we know the supplier and can take any action we want.

Okay, not it appears that you do not understand. Let's start with some
simple definitions, and forget "offsite" and "onsite".

client: the person or computer visiting your site

server: the computer with the webserver, mailserver handling your site

server-side scripting: runs computer with the webserver serving the
website, GGI, PHP, etc...

client-side scripting: runs in the browser of the client viewing your
site, i.e, JavaScript

mail-server: program that runs on the server that transports POP email
messages from one client to another

mail-client: the program on the client that communicates with the remote
servers to send and receive email, e.g., Outlook, Outlook Express,
Thunderbird, etc.

Now using a "mailto" in a link or as a action in a form is not
recommended for the reasons that Adrianne lists. Its ability to "work"
is predicated on the client having a mail-client installed on their
computer. If they don't then you get NO message. The mailto: link or
action needs to mail-client to compose the email and your clients have
to click send to send the message to their ISP's mail-server in order
for you to get the email. There is no way that you can from the server,
redirect, validate, filter, or even confirm that your client clicked the
send button on their email client!

With a mailto: the only filtering and v=checking for malicious data
would require client-side scripting, JavaScript, that you cannot rely on
being enabled.

Now the *only* reliable way to do what you wish is with server-side
scripting. The form's action goes to a server-side script (language of
your choice) in your server. That script can

* validate the data
* filter out and malicious data
* compose and arrange and format the email
* send email to your server's mail-server
* send messages to other email addresses, like notices to you
* log info to file on server or database
* send "courtesy" reply email to the client
* much, much more...

 

[Adrienne Boswell]

And while on the subject of cookies:-
I couldn't sign into this Google Groups Forum (ONLY, of all the 10
or so I contribute to or learn from), because it uses ANOTHER cookie
unrelated to "the site I am visiting". Seems to be new this week!
Found how to fix that one...

Then you need to wean yourself from Google's teat and get yourself a real
news client.

 

[Terence]

*****response being replied to as (nearly) all UPPER case******

Okay, not it appears that you do not understand. Let's start with some
simple definitions, and forget "offsite" and "onsite".

client: the person or computer visiting your site

THERE ISN'T SUCH A PERSON OR SUCH A SITE!

server: the computer with the webserver, mailserver handling your site

THERE ISN'T A WEB SERVER except in case A), below, a local
emulation of one.
THERE ARE TWO MAILSERVERS
case A) out and back via one mail service. Sender and receiver
are the SAME person
case B) message sent by user to Mr X, who sends reply back to to
user (two services).

server-side scripting: runs computer with the webserver serving the
website, GGI, PHP, etc...

THERE ISN'T ANY SUCH PROGRAM OR SERVICE

client-side scripting: runs in the browser of the client viewing your
site, i.e, JavaScript

THERE IS ONLY HTML IN THE FORM

mail-server: program that runs on the server that transports POP email
messages from one client to another

** THIS IS CORRECT. There are one, or two, services involved. **

mail-client: the program on the client that communicates with the remote
servers to send and receive email, e.g., Outlook, Outlook Express,
Thunderbird, etc.

(Almost, but misleading). THERE ARE ONLY A BROWSER AND AN E-MAIL
SERVICE.

Now using a "mailto" in a link or as a action in a form is not
recommended for the reasons that Adrianne lists. Its ability to "work"
is predicated on the client having a mail-client installed on their
computer.

TRUE, BUT SINCE THAT IS THE ONLY WAY THEY RECEIVE THE FORM, THEY
*HAVE* AN E- MAIL SERVICE!

If they don't then you get NO message. The mailto: link or
action needs to mail-client to compose the email and your clients have
to click send to send the message to their ISP's mail-server in order
for you to get the email.

THIS PART IS CORRECT. BUT Mr X HAS AN E-MAIL SERVICE WHICH GAVE HIM
THE FORM.

There is no way that you can from the server,
redirect, validate, filter, or even confirm that your client clicked the
send button on their email client!

THERE IS NO SERVER! But if he does'nt click there is no return
message either. So we DO KNOW!

With a mailto: the only filtering and v=checking for malicious data
would require client-side scripting, JavaScript, that you cannot rely on
being enabled.

WHATEVER DATA ARRIVES BY E-MAIL is, with the field ID code, either
coded button choice(s), or a number value or a text string. The text
is linguistically parsed for sense on processing in the indicated
language. The other fields match the nature of the each field. It
would be difficult to compose return values and text that are not
obvious rubbish. And since Mr X.is always known to us, there is action
we can take. (and his user name and address and URL are on the dummy
message)

Now the *only* reliable way to do what you wish is with server-side
scripting. The form's action goes to a server-side script (language of
your choice) in your server.

NO SERVER AGAIN!

That script can

* validate the data
* filter out and malicious data
* compose and arrange and format the email
* send email to your server's mail-server
* send messages to other email addresses, like notices to you
* log info to file on server or database
* send "courtesy" reply email to the client
* much, much more...

Thanks fo the trouble taken. Jonathan, but it only applies wo forms
placed on a web-site for casual selection and filling.

But Oh Dear! I'm really not getting through, am I?

There IS NO website where we are putting forms to be filled in, or
attract users.!
See inserted comments in the statements above which pre-suppose a web
server which does not exist and therfore is not involved.

So there are no Internet-web-based programs being run (other that any
persons normal e-mail service).

TWO CASES ONLY:

A) The form is LOCAL; the form is requested to be loaded LOCALLY in by
the browser from the LOCAL hard disk (e.g. by clicking on
"formname.htm" or by executing "run browser formname.html" by a batch
command which can also be clicked on the destop. The form is then
filled in by the user and on clicking on "SUBMIT" with a method of
"POST" and defined "mailto:", the data
i) is sent to the user's own mailbox either via internet or
ii) is sent via a "tinyweb" local server also back to the users
local mailbox (all on the same computer).

B) The user sends to Mr X, a message asking him to please complete the
attached form (with his browser of choice) by clicking on the form
name in the message, then completing the form, and then clicking on
"submit".
In which case the form is sent from Mr X's computer, via the Internet
e-mail service to the user's mailbox and we get a dummy message
showing he replied, and a file in the attach folder.

In case A) Locally, the tiny web server is a near do-nothing program
that writes to disc (to the user's e-mail attach directory), the coded
form data.
In case B) Mr X's browser does the encoding and sends a dummy message
with the form data as an attachment and which message then ends up in
the originator-user's e-mail box and the encoded form data in the
"attach" directory..

Currently (last 10 years) we use method B) in two styles
1) User to internet and back (user also being "Mr X" every time he
fills a form)
2) User sending to Mr X, who then sends back a dummy message and the
data to the user.

I can reply to any further questions other her or privately - no
problem!

I think what I wish to do should be available in ANY browser - to, IF
WORKING OFFLINE, BE PERMITTED TO STORE OR SAVE THE FORM DATA CONTENTS
IN A LOCAL text FILE..

 

[Terence]

Then you need to wean yourself from Google's teat and get yourself a real
news client.

Not available where the government owns the only from-outside service
facilities.
Also not available when the alternative permitted seach and e-mail
service is Google's!.

 

[Jan C. Faerber]

And while on the subject of cookies:-
 I couldn't sign  into this Google Groups Forum (ONLY, of all the 10
or so I contribute to or learn from), because it uses ANOTHER cookie
unrelated to "the site I am visiting". Seems to be new this week!
Found how to fix that one...

Which google group forum?

 

[Jonathan N. Little]

TWO CASES ONLY:

A) The form is LOCAL; the form is requested to be loaded LOCALLY in by
the browser from the LOCAL hard disk (e.g. by clicking on
"formname.htm" or by executing "run browser formname.html" by a batch
command which can also be clicked on the destop. The form is then
filled in by the user and on clicking on "SUBMIT" with a method of
"POST" and defined "mailto:", the data
i) is sent to the user's own mailbox either via internet or
ii) is sent via a "tinyweb" local server also back to the users
local mailbox (all on the same computer).

Okay, then HTML form with a mailto: is *still* not the way to do what
you wish, you need an application like e-registration with program
installers.

B) The user sends to Mr X, a message asking him to please complete the
attached form (with his browser of choice) by clicking on the form
name in the message, then completing the form, and then clicking on
"submit".
In which case the form is sent from Mr X's computer, via the Internet
e-mail service to the user's mailbox and we get a dummy message
showing he replied, and a file in the attach folder.

Cannot be done with HTML. Once the form with the "mailto" launches
email-client (IF there is one) there is no way to confirm that the guy
click the send button other than you received the message.

In case A) Locally, the tiny web server is a near do-nothing program
that writes to disc (to the user's e-mail attach directory), the coded
form data.
In case B) Mr X's browser does the encoding and sends a dummy message
with the form data as an attachment and which message then ends up in
the originator-user's e-mail box and the encoded form data in the
"attach" directory..

"attach" directory? This still is predicated on Mr X having an email
client. He may not, and your method will fail.

Currently (last 10 years) we use method B) in two styles
1) User to internet and back (user also being "Mr X" every time he
fills a form)
2) User sending to Mr X, who then sends back a dummy message and the
data to the user.

If this is some kind of program or installer, a much better strategy is
have the program open a URL an online website with an actual
registration form and to it properly. Example here Windows batch file:

REM Launch default browser to registration form
start http://www.example.com/registration.cgi

Batch file it primitive but essentially what your app would do...

I can reply to any further questions other her or privately - no
problem!

Not going to happen, this is Usenet not a help desk.

I think what I wish to do should be available in ANY browser - to, IF
WORKING OFFLINE, BE PERMITTED TO STORE OR SAVE THE FORM DATA CONTENTS
IN A LOCAL text FILE..

The restriction of a web browser's access to your local file system is
intentional for security reasons.

 

[Raymond Schmit]

<snip a long text>

The best way of achieving what you want to do is:

- Install a webserver locally on your machine.
- Install php that could be used by your newly installed webserver.
- Put your html form into the web-directory of your webserver.
- Follow the consels given here to initiate a "mailer.php" by the
submit of the "myform.html"
....the "mailer.php" will easely and sucessfully take all the form
zones and put them in a mail sent by the php command : mail();

 

[Jonathan N. Little]

<snip a long text>

The best way of achieving what you want to do is:

- Install a webserver locally on your machine.
- Install php that could be used by your newly installed webserver.
- Put your html form into the web-directory of your webserver.
- Follow the consels given here to initiate a "mailer.php" by the
submit of the "myform.html"
...the "mailer.php" will easely and sucessfully take all the form
zones and put them in a mail sent by the php command : mail();

Last step won't work unless you also install a mailserver as well.

 

[Raymond Schmit]

Last step won't work unless you also install a mailserver as well.

Sorry, it works here without installing locally a mailserver.
Here is an extract of my php.ini file:

[mail function]
; For Win32 only.
; was SMTP = localhost
SMTP = smtp.scarlet.be
; was smtp_port = 25
smtp_port = 25

Scarlet is my ISP and he will not allow that we use a mailserver nor
an ftpserver on our pc.

 

[Terence]

<snip a long text>

The best way of achieving what you want to do is:

- Install a webserver locally on your machine.
- Install php that could be used by your newly installed webserver.
- Put your html form into the web-directory of your webserver.
- Follow the consels given here to initiate a "mailer.php" by the
submit of the "myform.html"
...the "mailer.php" will easely and sucessfully take all the form
zones and put them in a mail sent by the php command : mail();

Already have general agreement that thi is correct.
But better still woould be direct write-to-disc when in safe off-line
mode.

 

[Terence]

Sorry, it works here without installing locally a mailserver.
Here is an extract of my php.ini file:

[mail function]
; For Win32 only.
; was SMTP = localhost
SMTP = smtp.scarlet.be
; was smtp_port = 25
smtp_port = 25

Scarlet is my ISP and he will not allow that we use a mailserver nor
an ftpserver on our pc.

This very brief note is very interesting.
I interpret (hopefully, and at least in Windows) that Raymond is
stating that one can redirect the local mail output function process
to a local port.
But the SMTP shown seems to be a server in Belgium, not a local
folder, and I'm sure more changes are needed in the TCP/IP protocol
manager, and also how the local port use can be implemented to store
to disc.
Or was this NOT the idea?

If Raymond or any other can amplify this concept, then everybody might
gain from this.
A succesful method would liberate the use of HTM/XHTHML etc forms to
efficient data capture.

Programs to parse and store data from the mailto-encoded encoded
data content from each form ares freely available form many sites
including our own.