using a general browser as a form-based capture method
in [JavaScript]
|
From: Terence on 15 Nov 2009 02:01 I should have noted that the user system for data entry is any Windows system (or even several kinds of DOS and even DOS emulation on a Macintosh). I used c:/directory/filename just as a common file example for Windows or MSDOS systems (either forms '//' or '\\' actually work, but some htm parsers seem to prefers a doubled slash to avoid code confusion. The processing system is currently Windows or MSDOS only, due to the API-type services needed.
From: Thomas 'PointedEars' Lahn on 15 Nov 2009 06:46 Terence wrote: > [...] I used c:/directory/filename just as a common file example > for Windows or MSDOS systems (either forms '//' or '\\' actually work, > but some htm parsers seem to prefers a doubled slash to avoid code > confusion. HTML has nothing to do with it. `//' is not a special markup sequence; it is the prefix of ECMAScript-compliant single-line comments, but any markup parser or script engine that recognizes it as such in a string literal is FUBAR. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Terence on 15 Nov 2009 17:36 On Nov 14, 1:17 pm, Terence <tbwri...(a)cantv.net> wrote: > I was rather hoping somebody can contribute to this question. > The browser must have the form data content in memory, plus the labels > and probably even a buffer with the proposed POST action text block. > All I wan to do is store this buffer (in Modzilla coded format) on a > local disk drive. I have been requested to post more detail. I am aware that for personal security reasons, browsers do not normally write to disc without going through an approved download process. But what if the browser is working OFFLINE? What happens to the form data? Are there then the same restrictions in force? I have computers that are never connected to any network, yet I use them for form generation and even web-site code testing via any (a few, precisely for testing) browsers. It has been suggested that the problem can (theoretically) be resolved by using something like TinyWeb on the same computer, so that the form posts to "localhost" and the web-server on the same computer (each and every one needed, else one local network server) then creates the usual dummy message and attaches the Modzilla coding of data contents (ALL browsers that process code seem to support the format) and sends the dummy message to the local web server. Then the web server takes the message and attached needed file and puts it in a local mailbox, which is also on the same computer.. Now, Tinyweb is a server program, with still huge resources and features, including a cgi processor (which implies it could process the form and send back error signals to the user....). This all seems to be a huge sledgehammer to crack a mustard seed. Since the browser must have the data from the Form in a buffer, (in order to create the message and attachment) all I need to do, is to get the action method="POST" to be modified to "simply" store the same buffer on disc. Even if it only works in OFFLINE mode. I have tested variations on the suggested (simple example) code below, that does some of this, but only stores the unlabled ascii-string contents of the fields filled ( think, from the WriteLine statements instead of ALL the form used), so (even if this was accepatable). Only my firewall asked if I wanted to store, and only the once. I have no idea of which fields they were and the post-processing is useless.. Remember, my object is to take any standard form HTM coding and insert (actually generate) a modified action section to allow this target operation. The result is a automated flexible general purpose data entry system (since I have the "after-posting and receiving" part of the form data processing already, that matches the original form generation from the original enquiring any-format document). <html> <head> <script language="javascript"> function Writedata() { var fso = new ActiveXObject("Scripting.FileSystemObject"); var write_id; write_id = document.getElementById('write_id').value ; var s = fso.CreateTextFile(write_id, true); s.WriteLine(document.getElementById('name_id').value); s.WriteLine(document.getElementById('id_id').value); s.Close(); } </script> </head> <body> name : <input type="text" name="name" value="" id="name_id"><br/> Address : <input type="text" name="id" value="" id="id_id"><br/> Write file to : <input type="text" name="write" value="c:/formdata/ filename.att" id="write_id"><br/> <input type="button" onclick="Writedata(this.form)" value="STORE"> </body> </html> And this is the structure of a typical form (id STUDY999) generation for such use, which will work offline, but reminds the user to get on- line again to send the data in the current "there-and-back" mode of use:- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional// EN" "http://www.w3.org/TR/html4/loose.dtd"> <html><head><title>STUDY999</title></ head> <form method="post" name="STUDY999" action="mailto:tbwright(a)cantv.net"> <input type="hidden" name="id" value="STUDY999"> <table width=100% border=0 bgcolor="#C0C0FF"><tr><td> <font color="#000000" size="+1"> [any form] </font></td></tr></ table> <hr><table cellspacing=0 cellpadding=0> <tr><td><font color="#000000" size= +1> Connect to the Internet for normal e-mailing, then click on <br> "Submit"; after which you can disconnect if you wish.</td></ tr> <tr><td align="center"> <input type="submit" value="Submit"> </td></tr></table></form></body></ html> Result:- In Modzilla format, the first string of the coding in the data file is id=STUDY999.:- id=STUDY999++&01%2F03-00=+1&01%2F04-01=+1&01%2F04-02=+2&01%2F04-03=+3 etc
From: Thomas 'PointedEars' Lahn on 15 Nov 2009 18:43 Terence wrote: > On Nov 14, 1:17 pm, Terence <tbwri...(a)cantv.net> wrote: >> I was rather hoping somebody can contribute to this question. >> The browser must have the form data content in memory, plus the labels >> and probably even a buffer with the proposed POST action text block. >> All I wan to do is store this buffer (in Modzilla coded format) on a >> local disk drive. > > I have been requested to post more detail. > > I am aware that for personal security reasons, browsers do not > normally write to disc without going through an approved download > process. But what if the browser is working OFFLINE? Doesn't matter. > What happens to the form data? The same as if you were "online". > Are there then the same restrictions in force? Yes, as long as you are not working in a privileged environment. > I have computers that are never connected to any network, yet I use > them for form generation and even web-site code testing via any (a > few, precisely for testing) browsers. > > It has been suggested that the problem can (theoretically) be resolved > by using something like TinyWeb on the same computer, I would use Apache, but it is all the same to the Web browser. It does not care that the host name is `localhost'. > Since the browser must have the data from the Form in a buffer, (in > order to create the message and attachment) all I need to do, is to > get the action method="POST" to be modified to "simply" store the same > buffer on disc. Even if it only works in OFFLINE mode. It does not work this way. An HTML form is designed to make HTTP requests. > Remember, my object is to take any standard form HTM coding and insert _objective_? > (actually generate) a modified action section to allow this target > operation. Parse error. > The result is a automated flexible general purpose data > entry system (since I have the "after-posting and receiving" part of > the form data processing already, that matches the original form > generation from the original enquiring any-format document). > > <html> > <head> > <script language="javascript"> Your markup is not Valid. <http://validator.w3.org/> > function Writedata() The identifier should start lowercase. > { > var fso = new ActiveXObject("Scripting.FileSystemObject"); > var write_id; > write_id = document.getElementById('write_id').value ; You can initialize the variable in the same statement (as above). > var s = fso.CreateTextFile(write_id, true); > s.WriteLine(document.getElementById('name_id').value); > s.WriteLine(document.getElementById('id_id').value); You could save three calls to document.getElementById() if you used the form object reference that you are already passing to WriteData(), which should be writeData(). For example: function writeData(f) { // ... var s = fso.CreateTextFile(f.elements["write_id"].value, true); if (s) { s.WriteLine(f.elements['name_id'].value); s.WriteLine(f.elements['id_id'].value); } // ... } > s.Close(); > } > > </script> > </head> > <body> > name : <input type="text" name="name" value="" id="name_id"><br/> Not Valid. <br/> is XHTML, not HTML. > Address : <input type="text" name="id" value="" id="id_id"><br/> `name' and `id' are two particularly bad names because it creates problems when accessing the corresponding form controls (or the form name or ID). > Write file to : <input type="text" name="write" value="c:/formdata/ > filename.att" id="write_id"><br/> `write' is not a very wise name for this either. And use a TABLE here instead. > <input type="button" onclick="Writedata(this.form)" value="STORE"> It should be obvious that `this.form' does not work without a FORM element. > </body> > </html> > > And this is the structure of a typical form (id STUDY999) generation > for such use, which will work offline, Maybe on your machine. > but reminds the user to get on-line again to send the data in the current > "there-and-back" mode of use:- Parse error. > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional// > EN" > "http://www.w3.org/TR/html4/loose.dtd"> What you declare is not what you write below, and vice-versa. > <html><head><title>STUDY999</title></ > head> This error is due to a Google Groups bug, I suppose. > <form method="post" name="STUDY999" > action="mailto:tbwright(a)cantv.net"> `mailto:' with forms has never worked reliably. Forget it. And method="POST" does not make any sense without a HTTP server. > <input type="hidden" name="id" > value="STUDY999"> > <table width=100% border=0 > bgcolor="#C0C0FF"><tr><td> There are required quotes missing around `100%', recommended quotes missing around `0', and the `bgcolor' attribute has been deprecated in favor of CSS more than 11 years ago. > <font color="#000000" > size="+1"> > > [any > form] > > </font> FORM is a block-level element, it must not be contained in an inline element like FONT. FONT has been deprecated in favor of CSS (`font-'*, `background- *', and `color' properties) more than 11 years ago anyway. The rest of your markup is awfully invalid, too. > [...] > Result:- > In Modzilla format, the first string of the coding in the data file Cannot parse "Modzilla format". There is no data file. There is an e-mail message at most. > is id=STUDY999.:- I do not think this is an exact representation of any data related to this code. > id=STUDY999++&01%2F03-00=+1&01%2F04-01=+1&01%2F04-02=+2&01%2F04-03=+3 Looks like percent-encoding according to RFC 3986 which is what can be expected from an HTTP (RFC 1945/2616) POST request but does not fit RFC 2822, of course. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: CaptainKirk1966 on 15 Nov 2009 21:32
On Nov 15, 5:36 pm, Terence <tbwri...(a)cantv.net> wrote: > On Nov 14, 1:17 pm, Terence <tbwri...(a)cantv.net> wrote: > > > I was rather hoping somebody can contribute to this question. > > The browser must have the form data content in memory, plus the labels > > and probably even a buffer with the proposed POST action text block. > > All I wan to do is store this buffer (in Modzilla coded format) on a > > local disk drive. > > I have been requested to post more detail. > > I am aware that for personal security reasons, browsers do not > normally write to disc without going through an approved download > process. But what if the browser is working OFFLINE? What happens to > the form data? Are there then the same restrictions in force? > > I have computers that are never connected to any network, yet I use > them for form generation and even web-site code testing via any (a > few, precisely for testing) browsers. > > It has been suggested that the problem can (theoretically) be resolved > by using something like TinyWeb on the same computer, so that the form > posts to "localhost" and the web-server on the same computer (each and > every one needed, else one local network server) then creates the > usual dummy message and attaches the Modzilla coding of data contents > (ALL browsers that process code seem to support the format) and sends > the dummy message to the local web server. > > Then the web server takes the message and attached needed file and > puts it in a local mailbox, which is also on the same computer.. > > Now, Tinyweb is a server program, with still huge resources and > features, including a cgi processor (which implies it could process > the form and send back error signals to the user....). > This is highly confusing. You are talking about a web server listening on localhost, receiving an html form posted from a browser on the same machine, and then e-mailing the form data back to a user on the same local machine ? Why would you want the server to e-mail the encoded form data back to a user on the same , rather than act on it directly and send the result back to the browser ? |