On Wed, Mar 31, 2010 at 3:01 PM, Eric Uhrhane <ericu@google.com> wrote: > On Wed, Mar 31, 2010 at 2:40 PM, Jonas Sicking <jonas@sicking.cc> wrote: > > On Wed, Mar 31, 2010 at 1:55 AM, Robin Berjon <robin@berjon.com> wrote: > >> On Mar 31, 2010, at 01:56 , Darin Fisher wrote: > >>> The only way to get a FileWriter at the moment is from <input > type="saveas">. What is desired is a way to simulate the load of a resource > with Content-Disposition: attachment that would trigger the browser's > download manager. > >> > >> I don't think that <input type=saveas> is a good solution for this, for > one it falls back to a text input control, which is less than ideal. I think > that the File Writer should trigger downloads on an API call since that > doesn't introduce security issues that aren't already there. I'll make a > proposal for that. > > > > Why not simply allow FileWriters be instantiated using: > > > > x = new FileWriter; > > > > And then make every call to .write open up the save as dialog. > > You wouldn't want to prompt on every write; developers might want to > append a chunk at a time. > You could prompt on creation, if you didn't mind that being a synchronous > call. > > The reason I made an html element be the way of getting a FileWriter > was to make the normal usage pattern not involve modal dialogs popping > up in front of the user unprompted. With an inpput control, they can > choose when to interact with it, rather than having a speedbump shoved > in front of them. > Please no more JS functions that block on modal dialogs! :-) @sicking: It seems odd to vary the behavior of .append based on how the FileWriter was created. Perhaps we should provide some other asynchronous means of creating a FileWriter? I also find it a little odd that we are overloading <input> to specify a save-as location. Has the idea of an <output type=file> tag been discussed? -DarinReceived on Thursday, 1 April 2010 08:04:23 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:06 UTC