Saving Recordsa Brute Force Approach
Normally, scripts running in the browser do not have access to the client's local file system. IE, however, has the ability to execute ActiveX controls which, when given permission, can access the local file system. You can make use of IE's built in FileScriptingObject to save files locally. Create a save() function in your script:
var saveType = "ud";
var forWriting = 2;
var dataFile =
var fso =new ActiveXObject
ts = fso.OpenTextFile(dataFile,forWriting,true);
//these lines clear the userData cache
// so the code will load only the
// latest saved version
The preceding code sets a few properties, instantiates the FileSystemObject, and then opens the underlying XML file as a writeable text stream. The third parameter indicates that the open method should create the file if it doesn't already exist. Passing the XML from the data island to the text stream's Write() method causes the data stored in memory to overwrite any data stored on disk. Closing the text stream flushes the buffer ensuring that the stream writes the data to the file. Finally, the code clears the userData cache so the page will retrieve the newly saved file correctly the next time the user views the page.
There are some obvious and potentially sinister shortcomings to the ActiveX approach. ActiveX controls require permission from the user to do their work. IE fires up an ominous message recommending that the code not be run at all (see Figure 1
You have three choices. The first two are to either reconfigure the client's browser settings so that it will run ActiveX controls without prompting (use IE's security settings to mark the site as trusted -- suitable for an Intranet application), or instruct the user to click "Yes" to execute the code. Marking the site as trusted creates a wide open security breach, because it gives any ActiveX control from that site carte blanche to create, copy, move, or destroy information on the local machine. Instructing users to let the code execute trains them to let other potentially unsafe ActiveX code run as wellsomething you should avoid out there on the wild, wild Web. The third possibility is to create a digitally "signed" ActiveX control. IE will ask the user if they want to install and run the control the first time the page is visited but subsequent visits will be seamless as long as the control remains installed. You can find out how to digitally sign an ActiveX control here
The hard coded file path is another problem with the ActiveX control approach. Hard coding paths is almost always a bad idea, because sooner or later you'll run into a situation where the path is invalid. If you leave out the path info, Windows saves the file to the user's desktop, which is not a palatable option.