I have a program where the user does some actions (i.e. clicking on several buttons). I want to record their clicks and the buttons that they click to allow the user to then download a text file with a record of their clicks when they click a separate "download" button. I looked at the File-system APIs for HTML 5, but they seemed to not have cross-browser support. I would ideally like to have this entire file generation and download scheme be entirely client-side, but I am open to server-side ideas as well.
TL;DR: Essentially I'm looking for an equivalent to Java's FileWriter, FileReader, ObjectOutputStream, and ObjectInputStream within Vanilla JS or jQuery (would like to stay away from php, but I'll use it as a last option).
Also, why don't all browsers support the filesystem api? (I'm guessing that it would make MSWord and Pages go out of business with all the open source clientside text editors that could come out.)
Unfortunately the HTML5-File-system is no longer a part of the spec, long story short FF refused to implement because they claimed everything you could do in the File-System API was doable in the HTML5 Indexeddb (which was mostly true). Please see this blog post for more on why FF didn't implement. I do not know IE's story. (I may have exagerated why FireFox didn't implement, I'm still bummed because you cannot actually do everything in indexeddb that you can do in the noew "Chrome File-system API")
Typically if two of those three browsers implement a spec, it stays in the spec. Otherwise that spec gets orphaned. However, I'm fairly certain a large reason the file-system api didn't take off is because of the IndexedDB API (caniuse IndexedDB) really took off when both specs were introduced. If you want cross browser support, check this api out.
That all said if you are still set on the file-system api some developers wrote a nice wrapper around the IndexedDB, the File-system api wouldn't actually supply you with a stream anyway. You would have to keep appending events to a given file given a fileWriter object. you'd then have to read the entire file and send to the server via an ajax request and then downloaded from the server once successfully uploaded.
The better route would be to use the IndexedDB apiwhich as stated on developer.mozilla
Open a database.
Create an object store in upgrading database.
Start a transaction and make a request to do some database operation, like adding or retrieving data.
Wait for the operation to complete by listening to the right kind of DOM event.
Do something
with the results (which can be found on the request object).
Here are a couple tutorials on the IndexedDB.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB
http://www.html5rocks.com/en/tutorials/indexeddb/todo/
As for giving the user that file, as mentioned briefly before you would have to upload the file to the server and download upon the "download" request. Unfortunately you have to trick the user into giving them the data already on their machine. Anyway, hope this all helps.
Related
I use Google's downloadDataURI function to download the PNG exported by a Google Chart.
In Chrome is working well, but in Firefox instead of downloading, replaces the html content with the PNG that is generated.
Anybody knows how to fix that behavior in Firefox?
First of all, this doesn't look like it is a Google project at all, but just a project somebody put up on the free Google Code hosting service (+ appspot)
What it does:
It checks if the browser is "webkit", and if not just changes the location to the data URI. This is exactly what happens in firefox and why the PNG is displayed instead of being downloaded.
Otherwise, it will construct a hidden <form> and <input> and post it to some random HTTP appspot server. And this does not sound very secure. The people running the appspot instance could log requests and/or a man-in-the-middle attacker could passively monitor the unencrypted transmission.
Honestly, I wouldn't use this service, ever, because I cannot trust the transmission channel, and I cannot trust the people behind it.
Instead, consider using <a download=... >, e.g. see Is there any way to specify a suggested filename when using data: URI?
I'm working on a Chrome extension to be used as an internal tool. Its required behavior is:
As a page action, enable an address bar icon when looking at certain intranet pages.
when the user clicks the icon, identify all files of a certain media type (say, .jpg) on the page, and
silently save them all to a directory on the user's local drive.
This question has been asked before, but the answer then was "use NPAPI", and NPAPI is now derelict.
So, what is the currently available way to achieve this? The ones I've looked at are:
The chrome.FileSystem API --- but this does not save files in any user-accessible location. Instead the stored files are hidden behind obfuscated names in an undocumented directory. User requires that the files be stored under their original names in an accessible directory.
The HTML5 download attribute, by creating a data: URL and programmatically clicking it. This pops up a "save as..." dialog for each file, which is unacceptable when there are a hundred assets on a single page. User requires that the files be downloaded without further interaction beyond the single icon click.
The Chrome Download API, but that is only available in the beta and dev channels. User requires this extension work with mainstream Chrome.
Use the Native Messaging API by creating a small .exe that simply saves a file to disk, and then pass the .jpg as a blob to it. This seems very cumbersome and I am not even sure how to reliably pass large blobs to EXEs like that.
Is there another approach I can try?
You've done quite a lot of research. Indeed, regular web pages cannot write to the user's filesystem without any plugins or extensions. Also, the HTML5 Filesystem API only provides access to a virtual filesystem, as you've observed.
However, you are confusing the chrome.fileSystem API with the HTML5 FileSystem API. Unlike the HTML FileSystem API, Chrome's fileSystem (app) API can directly write to the user's filesystem (e.g. ~/Documents or %USERPROFILE%\Documents), specified by the user.
This API is only available to Chrome apps, not extensions. This is not a problem, especially since you're developing an internal tool, because you can install the app and extension, and use message passing to communicate between the extension (page action) and app (file system access) (example).
About chrome.downloads: Since your extension is internal, you can probably force users to get on the beta/dev channel in order to use this API. The only limitation of this API is that the files will be saved in (a subdirectory of) the user-defined Downloads folder.
EDIT: The chrome.downloads API is now avaiable in all channels, including the stable branch (since Chrome 31).
I am afraid that you have done your homework, meaning you looked at all possible alternatives.
The best way to achieve exactly what you want, would be (as you mentioned) using a supporting native app and communicating through Native Messaging. BTW, since bandwidth is rarely a problem on intranets, you might find it simpler to pass the resources (e.g. images) URLs and have the app download and save them.
(Yes, it will be more cumbersome than simply developing an extension, but one's got to do what they've got to do, right ?)
On the other hand, if you are willing to sacrifice a little bit of user's experience over simplicity of development, I suggest combining the HTML5 goodies (that allow you to create and download a file locally) with a JS zipping library (e.g. JSZip), so the user only has to download a single zip file (and is only prompted once). BTW, if the user wishes, he/she can choose to always download the files without prompting (but you knew that already).
Use the Native Messaging App idea.
The native app is cumbersome and a pain to write because documentation is poor, and unless you get the JSON formatting exactly correct on both ends you will not see anything in a console because stdin and stdout are taken over.
But, you will be happier when it is done because you can use standard tools (e.g., Windows Explorer, a hex editor, TeamViewer...) to view, move, and delete files, and otherwise see what is going on. Chrome's sand-boxed file system works, but seems to now be a dead-end (no other browsers have picked it up). No one is likely to develop third-party tools for it. Of course you probably don't need tools once everything is working, but until then, debugging is a nightmare because you need to write code (and quite a lot of code) just to track what files are in what directories, file versions, remaining disk space...
Another solution for internal (or may be non-internal) usage is to connect to a websocket server, local or remote.
You can put it in both background.js or content.js (use wss:// for https://)
var ws = new WebSocket('ws://echo.websocket.org');
// var ws = new WebSocket('ws://127.0.0.1:9000');
ws.onmessage = function(res) {
console.log('received data:', res.data);
};
ws.onopen = function() {
ws.send('hello');
};
We are in process of building conceptual model of web-based audio editor. And the first trouble we met is client-side caching system. In my opinion as server-side programmer having huge cache on client side is perfect idea, because in many cases it takes of server load by excepting multiple loading of the same data. Furthermore such cache could be good candidate for buffer for providing per-track operations, like filtering.
Our flex programmer says that this is a great trouble and it is impossible in almost any cases. But I am in great doubt, cause I know that actual Google Chrome browser version can simple keep up to 2 Gb in localStorage. Moreover I've found this example of online track-editor and looks like its caching mechanism working pretty good.
Is it possible to cache some data (smth about 100-200mb) on the client side using flash and js?
You can use SharedObject to store the data.
I am pretty sure that default size limit is too low for your needs, so your app will need to ask user to accept your new limit:
http://www.macromedia.com/support/documentation/en/flashplayer/help/help06.html
SharedObject is more reliable than the browser cache, and you control it from your app.
If you are using html5 then you can store large data on client side using html5 inbuilt database.
also refer this link
What we did when writing a video editor. Well, actually, in Flash you can save files to the user's machine, with the restriction that it must be transparent to the user (i.e. the user initiates the action, goes through the OS dialog and saves the file as they would normally save anything they download), similarly, you can load in a file from a user's computer, with the restriction that the user must initiate the action (as in by clicking with a pointing device or pressing a key).
This has certain advantages over different local storage strategies, which are mostly opaque to users (people don't usually know how to erase cookies, SharedObjects or web storage that comes with more modern browsers, but they are pretty much capable of saving and deleting the files on their system). Furthermore, all other opaque local storages may have restrictions that less savvy users might not know how to overcome / may not be possible to overcome in general - these would be size, location and ownership.
This will still be a bit of hindrance for your audience, because every time they need to save a file, they have to go through the OS's dialog, instead of doing Ctrl+S / Cmd+S / C-x C-s... But given all other options, this, IMO, leaves the user with the most choices / delivers best experience.
Another suggestion - you could, in principle, come up with a browser-based "enhanced" version of your application, which users would install as a browser plugin (if that's an editor they are using on a regular basis - why not?), in which case you wouldn't be limited to the clumsy options provided by web technologies. Chrome and Mozilla-based browsers encourage such development, however it's not standardized. Still, since these two browsers run on virtually any OS, that doesn't sound particularly as locking in your users into a certain platform...
There's this website which has a javascript method in it that downloads a file. To call this method you have to set what language and serial number you're looking for and when that's done, the file is being generated according to the specified information you've just stated and then the file is being downloaded. Does anyone know how to specify this information, then send it and then download the file without going to this website?
Thanks in advance, Steve-O
If you use any tool that shows you what actual networking happens, you can discover the specific web requests that downloads the file. Chrome has those tools built in. The Firebug add-on adds those tools into Firefox. There are also apps that record all networking to/from the browser such as Fiddler which can be used to sleuth on the networking being done.
Of course, there may also be some authentication going on (a log-in, some cookies, etc...) that might be required, but all of that is visible with the right developer tools. Once you see exactly what is being sent over the wire, it's usually not hard to send that same request without a browser or without visiting that web page. If login credentials are required, that will still be required, but even that can be provided without a browser (e.g. from a server-side script).
JavaScript, as of the moment, can't download files. So how files gets downloaded? Well, the developer redirects the browser to a URL using
location.href = 'http://site.com/download.zip';
When the browser is redirected to this URL, it can't open the file, so it downloads it.
You need to determine that URL the browser redirects to. There are many ways to do that. One that comes to mind is the Fiddler app that records each HTTP request and thus can give you the URL.
My guess, however, is that the URL is generated on the fly. You need to study the JavaScript in this case and see the required mechanism to make the server generates the URL.
I need to update a pair of old classic asp pages— a search.asp page that provides a simple form which is then posted to a results.asp page. One of the form options on the search page is a drop down list (<select) for the "format". If the user chooses the excel format the results page just sets the Response.ContentType to application/vnd.ms-excel and adds a content-disposition header to set the file name and make it an attachment. That's it: it's up to excel to then correctly render the html, and it generally does a pretty good job.
All that works pretty well, except for one thing. The reason for the Excel option is that in this case the users really do want to see as many as 10,000 items or even more for a single search. They'll use Excel to do some additional analysis on the results. So the search operation typically takes just over a minute and I can't change that.
The user experience during that minute is less than ideal. Not only is the user just sitting there with little to no feedback, but there are often enough results that the page overflows the response buffer. This means the page has to flush periodically, and therefore the file starts downloading right away but the download manager isn't able to provide meaningful feedback by itself. My mission is to improve the situation.
The first step is to just show a simple processing... message on the search page when the form submits, and I can do that easily enough. In fact, it's been doing this already for the "HTML" format option. The problem is that when downloading the Excel file I don't know how to tell anything about the download so I can hide the message again, and the existing implementation doesn't provide any feedback on download progress at all. Any ideas? If I can just get a javascript function to fire when the download completes I can hook just about anything to that, but I can't even do that yet.
Update:
I re-worded the question to try to present the problem more clearly.
As far as I know, browsers don't offer you any hooks as to how far a download has progressed. In theory, you could do something on the server side and use AJAX to query the server to see how much of the download has been sent, but I don't know how to do it.
hmm, would it be possible to do this via ajax maybe? ie, user selects the format, query is sent via ajax, and the appropriate document is loaded into an iframe on search.asp for example. you could then pick up the succesful event in your ajax call and appropriately deal with the messages.
I would recommend looking into modifying your upload method to use something like SWFUpload which allows for JavaScript callback on the code. Once the file is uploaded (assuming you are storing it), I would look into passing the filename and type to your Results.asp page where it would then retrieve it form the file store. It's not as secure as keeping it in memory which you elude to in your question; however, would provide a better user experience and may provide the callback solution you need.
http://swfupload.org/
Here's a jQuery plug in example that makes the upload process and SWFUpload integration easy:
http://blog.codeville.net/2008/11/24/jquery-ajax-uploader-plugin-with-progress-bar/
You could have the file download as an attachment by adding a header, so that the user's browser remains operational. I realize this isn't exactly what you're asking for; but if you combine this with the interstitial page you are using for the HTML version, it might be an improvement for user experience.
Response.AddHeader "Content-Disposition", "attachment; filename=report.xls"
The user would see the interstitial page with the processing graphic which would then re-post the search form. This would allow the "Processing..." graphic to display until the page popped up with a download prompt for the Excel file.
Update: I tried using an iframe, having the page periodically check the document object and trapping the "interface does not exist" error for when it switches to Excel, but it still locks the browser while the Excel document is downloading in the iframe... I don't think a pure js solution is going to work. After that I think the next best avenue to pursue is (unfortunately) Flash. Good luck.