Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0
-
Fix Version/s: 3.2
-
Component/s: Sample Apps
-
Labels:None
-
Environment:ACE
-
Affects:Sample App./Tutorial
Description
The existing MD5 tutorial shows how do update the FileEntryStatus to reflect a success and a failure, but the failure won't actually ever happen. ICE-7712 was from us not testing the failure case either. So, let's augment the tutorial to allow for actually passing and actually failing.
We should set a maximum file size, which would show pre-failing, and then do the MD5, and succeed after that, but then fail on some condition, like a file extension being JPEG pr something like that.
We should set a maximum file size, which would show pre-failing, and then do the MD5, and succeed after that, but then fail on some condition, like a file extension being JPEG pr something like that.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
For reference, the tutorial documentation is on the wiki here: http://wiki.icesoft.org/display/ICE/Incremental+Upload+Processing+Using+FileEntryCallback
Show
Matthew Cowell
added a comment - For reference, the tutorial documentation is on the wiki here: http://wiki.icesoft.org/display/ICE/Incremental+Upload+Processing+Using+FileEntryCallback
When an uploaded file has failed built-in validation (maximum file size, etc.) then it will call validationFailed() and renderResponse() on the FacesContext. If the app then makes the upload be a success, and no FacesMessage explains how or why the form validation failed and why the bean state hasn't been updated, that could get quite confusing. So, pre-fail -> success is problematic. But, taking an initially successful upload, and having the app custom fail it, due to file extension or some other arbitrary measure of the file, is quite doable.