Re: Please add constructors for File and FileList

Greetings Victor!

>
>
> On Dec 10, 2012, at 12:02 PM, Victor Costan wrote:
>
> > Dear Web Applications WG,
> >
> > 1) Please add a File constructor.
>
>
> This has cropped up a few times :)  I've logged a spec bug for this
> feature: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20887
>
> Could you flesh out your original use case a bit more?  As currently
> expressed, it sums up to "I could write better unit tests" which doesn't
> constitute what I'm looking for in a use case.
>

My view on this sort of thing is always different: there should always be
exposed constructors for interfaces for which there are observable
instances in the scripting environment. The debat, then, is what they
should do. For that we need use-cases.


> It strikes me that the chief ask is to bind a Blob to name.  This would
> make life simpler with FormData and with existing server applications.
>  It's been pointed out that the barrier between Blob and File is pretty
> thin, and I'm open to jettisoning the thought pattern that we should think
> of File objects as strictly filesystem backed ("on disk").  So, what if we
> allowed the Blob constructor to take a name also?  This might allow Blobs
> to fall into the "80" of the "80-20" rule :)
>
> Could you update the bug (or this listserv) with better use cases?
>
> I'm a bit less upbeat about:
>
>
> > 2) Please add a FileList constructor.
> >
> > What I really want is "some way to add files to an <input
> > type="file">" listed in
> >
> http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest
> >
> > I think that one reasonable way to get there is to have a FileList
> > constructor that takes an array of File instances, and have the
> > ability to assign that FileList to the files attribute of the <input>.
> > This avoids making FileList mutable.
> >
> > This would also help me write better tests for my code. Currently,
> > <input type="file"> is the only form field whose value can't be set
> > inside JavaScript, so I can't write automated tests for <input
> > type="file">-related code.
> >
> > Asides from improving testing, this would allow me to implement the
> > following _easily_:
> >
> > * "filters" for uploaded content (e.g. resize a big image before
> uploading)
> > * "saving" the file a user selected in an IndexedDB, and "loading" it
> > back into the <input type="file"> if the page is accidentally
> > refreshed
> >
> > These features can be implemented without FileList support, but they
> > impact the application's design. For example, filters can be
> > implemented using FormData from XMLHttpRequest level 2 to upload
> > Blobs, but switching from plain form submission to XHR-based
> > submission can impact other parts of the application code, whereas
> > changing the files behind the <input> would be a localized change.
>
>
> As it stands currently, a FileList object typically stems from user
> action.  For instance, interacting with the file picker or with drag and
> drop.  In general, this model is desirable for security reasons -- the
> legacy HTML form and file picker ensures that web applications aren't doing
> things they shouldn't be doing with the underlying file system without user
> participation. I don't actually think it is desirable to modify <input type
> = "file"…> from within JavaScript.
>
> I'd like a better understanding of the broader implications of a FileList
> constructor, just out of abundant caution.  I have similar concerns about
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 which is also filed
> on the FileList object, but these seem easier to manage.
>
> Hope to hear back,
>
> -- A*
>
>
>
>
>