how to capture locally, the data content of an HTM form?
Terence
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
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.
Adrienne Boswell
writing in
news:568c90ea-2a8d-45fe...@m33g2000pri.googlegroups.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%2F06-02
> +2&01%2F06-03=+3&01%2F06-05=+5&01%2F07-01=+1&01%2F07-03+3&01%2F08-00
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
Terence
> Gazing into my crystal ball I observed Terence <tbwri...@cantv.net>
> writing innews:568c90ea-2a8d-45fe...@m33g2000pri.googlegroups.com:
>
> --
> Adrienne Boswell at Home
> 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!
Adrienne Boswell
writing in
news:cd98ba1e-23ab-4390...@u36g2000prn.googlegroups.com:
> 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...@m33g2000pri.googlegro
> 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
>> 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.
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
> 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
Thanks Jan. Wa interesting 2005 forum exchange.
Terence
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
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
Adrienne Boswell
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...
>
> --
> Take care,
>
> Jonathan
> -------------------
> LITTLE WORKS STUDIOhttp://www.LittleWorksStudio.com
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
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
wrote:
<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
Last step won't work unless you also install a mailserver as well.
Raymond Schmit
<lws...@gmail.com> wrote:
>Raymond Schmit wrote:
>> On Mon, 23 Nov 2009 23:25:36 -0800 (PST), Terence<tbwr...@cantv.net>
>> wrote:
>>
>> <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.
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
> On Mon, 23 Nov 2009 23:25:36 -0800 (PST), Terence <tbwri...@cantv.net>
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.
Jonathan N. Little
> On Nov 26, 7:22 pm, Raymond.Sch...@pircarre.be (Raymond Schmit) wrote:
>
>> 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?
Raymond is running w webserver with PHP, that is the setting for PHP to
relay email to his ISP's mailserver. Your stipulation was there was to
be no servers installed locally just plain HTML off of the local
filesystem.
Terence
No, NO and NO!
My stipulation was that there was no need for a server on the Internet
to be presenting the form to the general public in any way, to invite
filling and correction and hence data capture.
My two case were (restating):-
A) persons to whom an e-mail was sent to, to complete an attached
form and have the e-mail service send back data. (Either we GET a
reply or we DON'T; and if WE DON't, we can ask why not. There is no
important uncertainty )
B) computer data-entry staff doing data entry via THE SAME FORM format
(a copy) and having data stored locally so that the same form data
processing is applied to both data origins (A and B).
This data-entry computer can be off-line for ever but needs an
emulator to catch the pseudo e-mailed data attachment and store it in
some "\attach" folder (for compatibility of file structure names)..
At least one other computer would be on-line to send e-mailed forms
and pick up e-mailed data, for case A.
I agreed with two posters that a solution might be a do-little-or-
nothing web server emulator on each of the not-even-connected-to-the-
internet computers that were being used for the data entry.
This is a common Market Research requirement. I've been in the
business since 1972 and used the e-mailed form approach at least 10
years..
Jonathan N. Little
<snip signature>
>
> No, NO and NO!
Apparently your not listening, what Raymond is doing requires a
webserver which per your criteria is NOT applicable, and NOT "very
interesting"
>
> My stipulation was that there was no need for a server on the Internet
> to be presenting the form to the general public in any way, to invite
> filling and correction and hence data capture.
>
> My two case were (restating):-
> A) persons to whom an e-mail was sent to, to complete an attached
> form and have the e-mail service send back data. (Either we GET a
> reply or we DON'T; and if WE DON't, we can ask why not. There is no
> important uncertainty )
>
> B) computer data-entry staff doing data entry via THE SAME FORM format
> (a copy) and having data stored locally so that the same form data
> processing is applied to both data origins (A and B).
> This data-entry computer can be off-line for ever but needs an
> emulator to catch the pseudo e-mailed data attachment and store it in
> some "\attach" folder (for compatibility of file structure names)..
>
> At least one other computer would be on-line to send e-mailed forms
> and pick up e-mailed data, for case A.
>
> I agreed with two posters that a solution might be a do-little-or-
> nothing web server emulator on each of the not-even-connected-to-the-
> internet computers that were being used for the data entry.
>
> This is a common Market Research requirement. I've been in the
> business since 1972 and used the e-mailed form approach at least 10
> years..
And what I have been trying to tell you is A) You cannot read or write
to the local filesystem via the browser or email client with pure HTML
form. and B) You can have a email account WITHOUT and email client
program, i.e., web mail only, were the mailto: action will fail. 10
years ago fewer people had web mail only...
Jonathan N. Little
> My two case were (restating):-
> A) persons to whom an e-mail was sent to, to complete an attached
> form and have the e-mail service send back data. (Either we GET a
> reply or we DON'T; and if WE DON't, we can ask why not. There is no
> important uncertainty )
<snip>
> This is a common Market Research requirement. I've been in the
> business since 1972 and used the e-mailed form approach at least 10
> years..
Lastly: if said HTML form is sent via email and the user just happens to
have an email client like Thunderbird, in order for the form field data
to aggregated onto the body of the return email it would require
JavaScript be emailed.
JavaScript *disabled by default* in email clients, even is M$'s Outlook
and OutlookExpress. It is a very different Web these days. Anyone who
would enable JavaScript in their email client is either insane,
incredibly naive, intellectually challenged, or all of the above. One
thing would be for certain, they'd be *pwned*
So I will stand by my assertion that your only real viable option is to
send you clients emails with a link to your survey form that is properly
processed on an online server. That way you can handle and process the
data anyway you wish regardless of clients' local machine software, OS,
or configuration.
Raymond Schmit
I give-up .... he did not want a viable/good solution, he is expecting
some miracle :-)
Jonathan N. Little
> I give-up .... he did not want a viable/good solution, he is expecting
> some miracle :-)
You are sooooo right there!
Terence
(snip)
> So I will stand by my assertion that your only real viable option is to
> send you clients emails with a link to your survey form that is properly
> processed on an online server. That way you can handle and process the
> data anyway you wish regardless of clients' local machine software, OS,
> or configuration.
That may turn out to be true form case "B" (by setting up an in-house-
only web). Case "A" will alsways be with us for the allowed
situations.
But again: neither I nor my company sends e-mailable forms to our
clients. We are a software company and it is OUR CLIENTS who send e-
mails to THEIR respondents, using OUR software, which we want to
update.
HTML form print-outs are often also used as OMR documents (the
difference is the presence or not of a timing track on either edges of
the paper pages. To HTML readers of the electronic media, this is just
decoration. OMR readers can cost $10k to $20k and need service
agreements, so many countries find manual data-entry is more economic.
Hence the interest in the ability to choose to data-enter the form
rather than automatically read them.
Further, some agreements between researchers and THEIR clients require
that no forms, data or paper ever leave the offices of the researcher
(and NOT to be exposed on the web). Examples: general election
tracking; new product testing; health-related documents. Note, the use
of CAPI, in-house, by the actual respondent is yet another case of the
no-on-web form filling of the "B" circumstances..
So, both we AND our clients are interested in the local use of any
HTML-type or related form which can be filled in locally and NOT be
exposed on the Web just to be able to get the data back to the same
(expletive) computer.
I still think that a browser should, IN OFFLINE MODE. be able to store
locally.
After all, that's exactly what our browsers do when we "open" an HTML
script for editing, testing and re-writing HTML forms.
So why can't the "test" of the HTML form also store the data loacally
if off-line?
What Raymond suggested may still be valid under the right
circumstances (local web).
Terence
> I give-up .... he did not want a viable/good solution, he is expecting
> some miracle :-)
No. I already found how to store data locally in on-line mode using
java script.
It's not an alternative that I like.
The problem is now finding how to easily insert a general-case java-
based form-parsing routine into any form to be used for local data
entry.
I was hoping to find how to sent options or traps to cause the memory-
queued form output to be re-directed to the local disk .
And while on the subject, some browsers don't send a dummy message
with a data file attached, but stick the coded data in the body of the
otherwise dummy message itself.
This is easily dealt with by the same parser that we use which sweeps
up messages and attachments form the In-box and .\attach file areas.
.
Terence
(etc)
P.S. We DO know how to write web-based java-scripted form-parsing code
since there are 3 forms on our own web-site to handle different levels
of enquiries and get the data back to us.
But that method is NOT what some of our clients need, but something
more private and more flexible and LOCAL.
The others are quite happy thank you.