Hello public-webapps, I've spent a bit of time with the filesystem API recently, building out a set of common file dialogs (open, save-as, etc) for ChromeOS. We have a private API call to get access to a special filesystem that contains the user's downloads folder and the mounted external storage, but beyond that the dialogs use the standard filesystem API calls.
The bulk of the code is here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/file_manager/js/ I've run into a few awkward bits that I'd like to bring up here to see what everyone else thinks. * The async API is really awkward when you want to resolve multiple entries. I have a case where I'd like to resolve a list of directories and then do something when that completes. It would be helpful if the DirectoryEntry class had a getDirectories() method. I've built my own in file_manager/js/util.js in the function called util.getDirectories. * That leads to a desire to get "entries" in the general sense. In my case I knew ahead of time that I had a list of directories. If I didn't know whether I had been handed directories or files, the code would get pretty hairy. So in addition to getDirectories, a getEntries method (and getEntry, too) would be super useful. * Another helper I found useful was util.forEachDirEntry from the same file previously mentioned. This function invokes a callback once for each entry in a directory. This saves the caller from having to create the reader and walk the results array during the callback. It makes client code significantly more readable. I'd love to see DirectoryEntry.forEach(...). * The FileError object is a bit awkward to work with. I found that I frequently had every reason to expect my calls to succeed (because they were a follow-on to something that already succeeded), but I wanted to log the failure reason in the event they didn't. The code online suggests a switch/case statement to turn error codes into mnemonic strings. This requires a hardcoded list of all known errors, and a call out to this utility function every time you want to display the error reason in a readable way. I suggest adding the mnemonic string as a property of FileError, and displaying it as part of the toString. (See util.getFileErrorMnemonic() and util.installFileErrorToString() for example implementations.) Rob.
