W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2011

[whatwg] creating a new file via the File API

From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Date: Mon, 19 Dec 2011 05:13:03 +0100
Message-ID: <4EEEB9CF.5020509@bauglir.com>
Hi,

This is quite crucial functionality and sadly not being addressed as it 
would seem, because without it application cannot really be applications 
(all you can do is to prepare data, upload those data to server and let 
user download it manually by clicking somewhere, which is annoying, 
unnecessary,  and quite frankly stupid) .


but there is a way howto allow user to save file from javascript without 
flash

http://www.webnt.cz/demos/034_a_download/

this demo (the generated files) allows you to download/drag'ndrop 
generated file using JS (no flash)
it's working in Chrome only at this point
FF team is having some security issues I've been discussing with them
https://bugzilla.mozilla.org/show_bug.cgi?id=676619



B.


On 16.12.2011 0:58, David Karger wrote:
> It isn't clear to me that a "tag" question can be addressed by an 
> "api" answer.   Even if there is an api for saving to file, isn't 
> there value to being able to declare your intentions through a tag?  
> The <input type=file> tag specifies that a user will be able to 
> interact to specify a file through a dialog.  There's absolutely no 
> commitment that that file will actually be uploaded or input.  That's 
> up to the form or the javascript that handles the input.  It seems 
> entirely consistent to be able to permit specification of a brand new 
> file in that dialog that <input type="file"> is already creating.   
> What some javascript _does_ with the specified file might need to be 
> implemented using a filesaver api, but that's separate from the 
> declaration of an interaction for specifying the file.
>
> On 12/15/2011 6:45 PM, whatwg-request at lists.whatwg.org wrote:
>
> On Mon, 15 Aug 2011, David Karger wrote:
>> /
> />/  Apologies if I'm revisiting old territory.  I've been doing work 
> on pure
> />/  html/javascript applications that work entirely clientside
> />/  (http://projects.csail.mit.edu/exhibit/Dido).  For persistence, they
> />/  read and write local files.  There's already an<input type="file">
> />/  interface for letting the user specify a file to be read.  And I 
> can use
> />/  the same interface, inappropriately, to let the user overwrite a
> />/  preexisting file.  But things get much messier if I want to let 
> the user
> />/  specify a _new_ file to be written, because the file-open dialog 
> doesn't
> />/  offer users a way to specify a new filename.  What I'd like to be 
> able
> />/  to do is specify a tag, or a invoke some javascript method, that 
> will
> />/  produce the "save file" dialog typical of most systems, with a 
> graphical
> />/  directory browser but including the option to specify a new 
> filename.
> />/  This problem isn't unique to me; a discussion on stackoverflow 
> appears
> />/  at
> />/  
> http://stackoverflow.com/questions/2897619/using-html5-javascript-to-generate-and-save-a-file
> />/  where the proposed solution is to use flash---and that would be an
> />/  unfortunate loss of html5 purity.  They also suggest the hack of 
> using a
> />/  data: url but that has size limitations.
> />/
> />/  Perhaps<input type="file">  could be given an attribute specifying
> />/  whether a new filename is permitted?
> /
> On Wed, 7 Sep 2011, Eric U wrote:
>> /
> />/  This sounds like a job for the FileSaver interface.  Currently no
> />/  browser implements it, but we at Chrome have been considering 
> it.  At
> />/  TPAC last year we discussed it a bit in the WebApps WG meeting; 
> IIRC we
> />/  talked about letting it take a URL instead of or in addition to 
> just a
> />/  Blob, for more general utility.
> />/
> />/  I suggest you bring it up on public-webapps@, where that spec lives.
> />/  
> http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSaver
> /
> I agree that an API like FileSaver is the right way to do this. Using
> <input type=file>  wouldn't really fit well because that's more for
> providing data for upload than providing a file for writing.
>

-- 

s pozdravem
          Bronislav Klu?ka



http://www.bauglir.com <http://www.bauglir.com>

http://www.bauglir.com
Bronislav.Klucka at bauglir.com  <mailto:Bronislav.Klucka at bauglir.com>

   * webov? aplikace
   * software na zak?zku
Received on Sunday, 18 December 2011 20:13:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:38 UTC