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

Discussion in 'HTML' started by Terence, Nov 17, 2009.

  1. Terence

    Terence Guest

    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.
     
    Terence, Nov 17, 2009
    #1
    1. Advertising

  2. 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.
     
    Raymond Schmit, Nov 18, 2009
    #2
    1. Advertising

  3. Gazing into my crystal ball I observed Terence <>
    writing in
    news::

    > 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
     
    Adrienne Boswell, Nov 19, 2009
    #3
  4. Terence

    Terence Guest

    On Nov 19, 11:40 am, Adrienne Boswell <> wrote:
    > Gazing into my crystal ball I observed Terence <>
    > writing innews::
    >
    >
    >
    >
    >
    > > 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!
     
    Terence, Nov 20, 2009
    #4
  5. Gazing into my crystal ball I observed Terence <>
    writing in
    news::

    > On Nov 19, 11:40 am, Adrienne Boswell <> wrote:
    >> Gazing into my crystal ball I observed Terence <>
    >> writing
    >> innews:

    > 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
     
    Adrienne Boswell, Nov 21, 2009
    #5
  6. On Nov 18, 12:26 am, Terence <> 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/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
     
    Jan C. Faerber, Nov 21, 2009
    #6
  7. Terence

    Terence Guest

    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, Nov 23, 2009
    #7
  8. Terence

    Terence Guest

    On Nov 22, 12:59 am, "Jan C. Faerber" <> wrote:
    > On Nov 18, 12:26 am, Terence <> 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/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


    Thanks Jan. Wa interesting 2005 forum exchange.
     
    Terence, Nov 23, 2009
    #8
  9. Terence

    Terence Guest

    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, Nov 23, 2009
    #9
  10. 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
     
    Jonathan N. Little, Nov 23, 2009
    #10
  11. Gazing into my crystal ball I observed Terence <> writing
    in news::

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

    --
    Adrienne Boswell at Home
    Arbpen Web Site Design Services
    http://www.cavalcade-of-coding.info
    Please respond to the group so others can share
     
    Adrienne Boswell, Nov 24, 2009
    #11
  12. Terence

    Terence Guest

    On Nov 24, 3:43 am, "Jonathan N. Little" <> wrote:
    > 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.

    >


    *****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, Nov 24, 2009
    #12
  13. Terence

    Terence Guest

    On Nov 24, 5:26 pm, Adrienne Boswell <> wrote:
    >
    > 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!.
     
    Terence, Nov 24, 2009
    #13
  14. On Nov 23, 12:08 pm, Terence <> wrote:
    > 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?
     
    Jan C. Faerber, Nov 24, 2009
    #14
  15. Terence wrote:

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

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Nov 24, 2009
    #15
  16. On Mon, 23 Nov 2009 23:25:36 -0800 (PST), Terence <>
    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();
     
    Raymond Schmit, Nov 25, 2009
    #16
  17. Raymond Schmit wrote:
    > On Mon, 23 Nov 2009 23:25:36 -0800 (PST), Terence<>
    > 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.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Nov 26, 2009
    #17
  18. On Wed, 25 Nov 2009 19:10:32 -0500, "Jonathan N. Little"
    <> wrote:

    >Raymond Schmit wrote:
    >> On Mon, 23 Nov 2009 23:25:36 -0800 (PST), Terence<>
    >> 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.
     
    Raymond Schmit, Nov 26, 2009
    #18
  19. Terence

    Terence Guest

    On Nov 26, 9:51 am, (Raymond Schmit) wrote:
    > On Mon, 23 Nov 2009 23:25:36 -0800 (PST), Terence <>
    > 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();


    Already have general agreement that thi is correct.
    But better still woould be direct write-to-disc when in safe off-line
    mode.
     
    Terence, Nov 26, 2009
    #19
  20. Terence

    Terence Guest

    On Nov 26, 7:22 pm, (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?

    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.
     
    Terence, Nov 29, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob

    Create htm file from Web Form

    Rob, Aug 22, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    2,105
  2. Max
    Replies:
    7
    Views:
    9,184
  3. hazz
    Replies:
    6
    Views:
    50,040
    SkyUCHC
    Jun 9, 2010
  4. Replies:
    6
    Views:
    1,371
    J.O. Aho
    Aug 19, 2007
  5. Replies:
    6
    Views:
    186
    Dr.Ruud
    Feb 6, 2007
Loading...

Share This Page