RF-12224: FileUpload - initial support for multiple file selection

[lfryc]

Opening pull request for a review.

[lfryc]

Couldn't we just change maxFilesQuantity attribute to Integer?

[simone83]

Yes of course we could, so I've changed related getter inside the AbstractFileUpload. See next comment.

[simone83]

:+1 . In this method we also need (but I'm sure that we cannot do that modifing only few sources :( ): <-- ahahah

• check the maxFilesUpload not only per-request but with all files uploaded. If not, we have the problem if an user first uploads K<N (let maxFilesUpload=N) files, then another request for other K<N files and that is going done because it will only check if K<N and it does. In the new fileupload.js I sent you today this is fixed, but we also do this fix at serverside (remember? It plays the game in a sort of amleto-boolean-logic : upload the whole files block or not upload?).
  This is not a great bug for now because the adviced user can avoid that problem inserting some logic inside the listener...
• another, similar bug of above, but related to the duplicates problem. Now we don't care about that at server-side and we have not a complete file list at server-side. Only the user's have that. We have only the files sent in the multipart per-request... so if we have > 1 request for upload several files, how can we do the check for duplicated filenames?
  We need to hack the javascript code for include an hidden attribute which contains the updated value of __getItemTotalCount() inside, so we can read that at server-side (dirty but hacky) if boolean isNoDuplicate() returns true. Similar as above, the adviced user can avoid this problem with a check of duplicates inside the bean which the listener is implemented.

OoooooooooooooookaY?

^ not intentionally, I've mirrored the worry face :( |I'm a mirror| ): !!!

[simone83]

we have to add

var itemsCount = this.__getTotalItemCount();

[bleathem]

This value should be cached in the component using the StateHelper, something like:
String acceptedTypes = (String) getStateHelper().eval("acceptedTypes");

[lfryc]

Actually, the we delegate to abstract method, which is implemented by UIFileUpload as:

public String getAcceptedTypes() {
        String value = (String) getStateHelper().eval(Properties.acceptedTypes);
        return value;
    }

[bleathem]

This looks really good, thanks for taking the time to create the patch @simone83! I made a couple comments inline.

Regarding the need for a multiple=true/false attribute for backwards compatibility, it's hard to say. I'd like to see what the usage of the fileupload component looks like with this new feature in place. I'll build the component in this branch, and try it in the showcase to try it out.

[bleathem]

Ok, I tired it in the showcase - it works great. I can't think of a use case for requiring users to select only a single file at a time, particularly with the getMaxFilesQuantity attribute that can be set to 1. @lfryc can you think of a use case requiring this?

[bleathem]

Possible bug: I tried uploading 2 files, the first one threw an exception that the filesize is too big, this blocked the upload of the 2nd file which was acceptable. Clicking the upload button a 2nd time allowed the upload time of the 2nd file to proceed.

IMO, if a file is invalid to be uploaded, it should not block the remaining files waiting to be uploaded.

[simone83]

Brian, thank you. I'm glad to join in richfaces community with great guys like you and lukas and give my contrib when i can. Concerning the getMaxFilesQuantity set to be 1 in case of single file at a time, note also we must mantain backward compatibility with some browsers like IE7 that does not recognize the multiple attribute in html component. In my first patch, and its subsequently changes it works in both versions of browsers. If u take a look inside fileupload.js in fact you can see the support for oldiest browsers:
so:
1) var multipleInputFiles = this.input.prop("files"); --> for multiple support
2) var fileName = this.input.val(); --> for old browsers single upload support

then the things should works on oldiest IE browsers and in newest Firefox too: the code in fileupload.js recognize if multiple upload is supported then will go in multiple mode, else it works in single upload mode (it does an if (this.input.prop("files")) so if it is true we are running on a browser that supports multiple upload, else nothing to do :( we have to go in single upload mode).
So we can not control the multiple feature only by maxFilesQuantity parameter because that structural differences, and we must auto-detect first what mode (single or multiple) the client browser -on we are running on - supports.
I think you know that as best as I know but ...guess it is best to explain all that tricks however...agree??!?! :)

[simone83]

Notice also we can do that (valid only on browsers that supports the multiple attribute):

var multipleInputFiles = this.input.prop("files"); 

for (var i = 0; i < multipleInputFiles.length; i++) {
  var fileName = multipleInputFiles[i].name; //this is the file name
  var fileSize = multipleInputFiles[i].size; //this is the file size
}

so we can act inside fileupload.js for implement client-side verification of maximum-file size exceed treshold,
so for example we can add a new exception: FileSizeExceededException.

function FileSizeExceededException(fileName) {
    this.name = "FileSizeExceededException";
    this.message = "The size of file " + fileName + " is greater than max size allowed";
    this.fileName = fileName;
}

• in __addItems we can add this check inside for loop:
  if (multipleInputFiles[i].size > MAX_SIZE) throw new FileSizeExceededException(multipleInputFiles[i].name);
  • and adding the binding to a new rf event "onsizeexceeded", either in fileupload.js and in component VDL

Notice also for mantaining the compatibility with single mode upload, where we can't rely on size attribute, we also need to delegate at user-implementation inside the bean listener to check the max treshold of a file size.
WDYT?

[bleathem]

Setting maxFilesQuantity=1 means the user can upload only a single file (total), not one file at a time. Form the VDL doc, maxFilesQuantity:

Defines maximum number of files allowed to be uploaded. After a number of files in the list equals to the value of this attribute, "Add" button disappears and nothing could be uploaded even if you clear the whole list. In order to upload files again you should rerender the component

But like I was saying, I don't think we need to provide an option to limit file selection to one at a time. If the browser supports it, let's run with it.

---

As for the Exception thrown while uploading a group of files, we should either:

1. look at modifying our exception handling to allow for updating the remaining files
2. modify the display to clearly indicate that the upload of the remaining files has failed

My preference is for 1)

[simone83]

Ok,i agree...that behavior of maxfilesquantity was well knew by me but probably I misread your related post reading "can" instead of "can't" sorry:(

[simone83]

Brian, I've done a new post (new re-edited for last time) concerning the "withoutextension." files,please read it because it is important...in it i describe a NEW FIX that resolves an issue in case of acceptedTypes=",EXT1,EXT2,...,EXTN"
including the empty string supporting the empty file-extension. Otherwise the actual implemention will fail if you try to upload a file without extension and any other file in same multiple-upload request, due the indexOf in fileupload.js@310. We can also avoid this fix but we have to change the syntax/logic of acceptedTypes field including the "." on the extension name...

...thank you!
Simone

[bleathem]

We don't have to go so far as to get the acceptedTypes attribute to work with empty extensions, but rather we should have the component fail when a file with an empty extension is uploaded (for example if I leave acceptedTypes unspecified).

[lfryc]

I'm going to work on merging this into RF 4.5.0 branch.

[lfryc]

Merged: 72417a9