using a general browser as a form-based capture method
in [JavaScript]
|
From: Thomas 'PointedEars' Lahn on 14 Nov 2009 04:29 Stefan Weiss wrote: > On 14/11/09 08:24, Stefan Weiss wrote: >> Note that the file path is now "C:/formdata/filename.att" instead of > > "C://formdata//filename.att". Why? Are you confusing slashes and backslashes by any chance? PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Stefan Weiss on 14 Nov 2009 09:40 On 14/11/09 10:29, Thomas 'PointedEars' Lahn wrote: > Stefan Weiss wrote: > >> On 14/11/09 08:24, Stefan Weiss wrote: >>> Note that the file path is now "C:/formdata/filename.att" instead of >> >> "C://formdata//filename.att". > > Why? Are you confusing slashes and backslashes by any chance? No, the OP's example used '//' as path delimiter. I'm not familiar enough with ActiveX to judge if there was any specific reason for that. I changed it to a single forward slash, which appears to work well enough with the ActiveX FileSystemObject and Mozilla's file API. cheers, stefan
From: Thomas 'PointedEars' Lahn on 14 Nov 2009 10:21 Stefan Weiss wrote: > On 14/11/09 10:29, Thomas 'PointedEars' Lahn wrote: >> Stefan Weiss wrote: >>> On 14/11/09 08:24, Stefan Weiss wrote: >>>> Note that the file path is now "C:/formdata/filename.att" instead of >>> "C://formdata//filename.att". >> >> Why? Are you confusing slashes and backslashes by any chance? > > No, the OP's example used '//' as path delimiter. I'm not familiar > enough with ActiveX to judge if there was any specific reason for that. > I changed it to a single forward slash, which appears to work well > enough with the ActiveX FileSystemObject and Mozilla's file API. I see, a misunderstanding. I read your statement above and assumed you introduced the double slashes because I could not find the path in the source code at first. However, both initWithPath() from XPCOM and CreateTextFile() from ActiveX/COM require a file path. It is unlikely that on a WinDOS system "C://formdata//filename.att" or "C:/formdata/filename.att" would be recognized as such. It is more likely that the OP confused slashes and backslashes in the first place, because "C:\\formdata\\filename.att" evaluates to `C:\formdata\filename.att', which is a WinDOS file path. I think your approach is too specialized, though. 3 stack levels for retrieving the value of a single form control which name is hard-coded in the third level? PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Stefan Weiss on 14 Nov 2009 12:17 On 14/11/09 16:21, Thomas 'PointedEars' Lahn wrote: > Stefan Weiss wrote: >> On 14/11/09 10:29, Thomas 'PointedEars' Lahn wrote: >>> Why? Are you confusing slashes and backslashes by any chance? >> >> No, the OP's example used '//' as path delimiter. I'm not familiar >> enough with ActiveX to judge if there was any specific reason for that. >> I changed it to a single forward slash, which appears to work well >> enough with the ActiveX FileSystemObject and Mozilla's file API. > > I see, a misunderstanding. I read your statement above and assumed you > introduced the double slashes because I could not find the path in the > source code at first. > > However, both initWithPath() from XPCOM and CreateTextFile() from > ActiveX/COM require a file path. It is unlikely that on a WinDOS system > "C://formdata//filename.att" or "C:/formdata/filename.att" would be > recognized as such. Forward slashes are valid path separators in Windows. Sometimes applications expect backslashes, but the system API and the FSO work with forward slashes, too. > I think your approach is too specialized, though. 3 stack levels for > retrieving the value of a single form control which name is hard-coded in > the third level? You mean the |getFilePath| function? Yeah, that one isn't really necessary. I could have read and validated the path in |saveFile|, but I don't mind a little extra indirection for well defined tasks. In this case it's especially useful, because we're writing to the local file system, and bad things can happen if the path is incorrect*. Using a separate function for this actually makes the code _less_ specialized, IMHO: the script I used as a basis already had a getFilePath() method, which combined the value from the text field with a BASE_PATH constant (/home/username/tmp/). All I had to do was adjust |getFilePath|'s implementation before I posted; the rest remained (more or less) unchanged. The other "stack level" - the |getVal| function - is indeed unnecessary. I only used it as a shortcut to keep the lines short enough. The finished script will probably use the form's |elements| collection. Terence's example even called |Writedata(this.form)| from the "STORE" button, but there was no form, so I left that out. cheers, stefan * This is somewhat mitigated by the fact that people are smart enough not to run Windows as administrator. *cough*
From: Terence on 15 Nov 2009 01:52
Thanks to Stefan! I'll try again. I have software than allows a user to take almost any document which claims to be some form of questionnaire (in any roman-alphabet or greek alphabet characters) and turns it into a valid web-based form for a web-site or for e-mailing to selected persons (or as a response to an e-mail). The sotware also writes all the processing control files needed by fixed programs, to statistically analyse the data, write reports and cross-tab tables and frequency tables. The software is compatible with several market research source code systems and can use these variuos defining systems and stored data formats, both ascii and binary. The existing forms as generated, automatically send the collected data back (BY E-MAIL), in the format used by all browsers that I have made use of, referred to as "Modzilla format" by those who have corresponded on the subject. However, for in-house data entry, it would be very convenient to use such a generated form to elicit data entry without input errors, complete with the checks and branching controls included. All that is needed, is to to change the ACTION=POST in the HTM to something else, covered by the jave-coded "ON-CLICK" submit button control, to store the same data locally on a local disc instead of sending as an attached file to the web and getting it back from there. Obviously, the Mdozilla-coded file is created; I just need to redirect it to local storage. |