«

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.

On Tue, 17 Nov 2009 15:26:38 -0800 (PST), Terence <>
wrote:

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

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

Gazing into my crystal ball I observed Terence <>
writing in
news:568c90ea-2a8d-45fe-a9cc-:

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

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.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

On Nov 19, 11:40*am, Adrienne Boswell <arb...@yahoo.com> wrote:
> Gazing into my crystal ball I observed Terence <tbwri...@cantv.net>
> writing innews:568c90ea-2a8d-45fe-a9cc-:
>
>
>
>
>
> > 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.
>
> 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.
>
> --
> Adrienne Boswell at Home
> Arbpen Web Site Design Serviceshttp://www.cavalcade-of-coding.info
> Please respond to the group so others can share


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!

Gazing into my crystal ball I observed Terence <>
writing in
news:cd98ba1e-23ab-4390-8f17-:

> On Nov 19, 11:40*am, Adrienne Boswell <arb...@yahoo.com> wrote:
>> Gazing into my crystal ball I observed Terence <tbwri...@cantv.net>
>> writing
>> innews:568c90ea-2a8d-45fe-a9cc-
> ups.com:
>>
>>
>>
>>
>>
>> > 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%2
> F06-02
>> > *+2&01%2F06-03=+3&01%2F06-05=+5&01%2F07-01=+1&01%2F07-03+3&01%2
> F08-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
>> > varyin
> g
>> > 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?
>>
>> Seehttp://www.cs.tut.fi/
~jkorpela/forms/andhttp://www.isolani.co.uk/ar
>> tic
> les/mailto.htmlfor more information.
>>
>> --
>> Adrienne Boswell at Home
>> Arbpen Web Site Design Serviceshttp://www.cavalcade-of-coding.info
>> Please respond to the group so others can share
>
>
> 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:
>> 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!
>

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

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

On Nov 18, 12:26*am, Terence <tbwri...@cantv.net> wrote:

> 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/4...ata-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

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.

On Nov 22, 12:59*am, "Jan C. Faerber" <faerber....@gmail.com> wrote:
> On Nov 18, 12:26*am, Terence <tbwri...@cantv.net> wrote:
>
> > 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/4...ata-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

Thanks Jan. Wa interesting 2005 forum exchange.

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

Terence wrote:
> 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.


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


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com