Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.7Beta1
-
Fix Version/s: 1.7.1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All
-
Support Case References:
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial
Description
Right now the InputFile component renders out an IFRAME tag with a src attribute which consists of a Javascript call do document.write() with the contents of the IFRAME. This IFRAME rendering code, in InputFile.renderIFrame(-), is invoked by both the InputFileRenderer, whenever the page renders, and also by UploadServer, once the file has completed uploading.
In synchronous mode, the InputFile.progressListener -> Bean -> OnDemandRenderer calls, and the InputFile -> PersistentFacesState.renderLater() call are both mostly useless, since they have no means to push those renders to the client.
The only thing that is being sent to the client, is the UploadServer response, in the form of the InputFile.renderIFrame(-). If this code could be adapted, to notify the web browser to initiate an update from its end, then we could get file upload completion notification, in synchronous mode. Possibly, with multi-part MIME, we could even get file upload progress notification.
Mircea says that because of security constraints in the web browser, we can't just render our javascript, to be executed from the IFRAME, to get the whole page's bridge to cause an update. Especially if using SSL. But, the IFRAME response could set a cookie, and the bridge could watch this cookie, and check for updates, based on it, much like how the receive-updated-views protocol works.
Of course it would be simpler to just have the UI for the progress and completion right inside the IFRAME itself, and not have to use the cookie trick. But there might be arbitrarily numerous changes to the UI, so that might not be feasible.
In synchronous mode, the InputFile.progressListener -> Bean -> OnDemandRenderer calls, and the InputFile -> PersistentFacesState.renderLater() call are both mostly useless, since they have no means to push those renders to the client.
The only thing that is being sent to the client, is the UploadServer response, in the form of the InputFile.renderIFrame(-). If this code could be adapted, to notify the web browser to initiate an update from its end, then we could get file upload completion notification, in synchronous mode. Possibly, with multi-part MIME, we could even get file upload progress notification.
Mircea says that because of security constraints in the web browser, we can't just render our javascript, to be executed from the IFRAME, to get the whole page's bridge to cause an update. Especially if using SSL. But, the IFRAME response could set a cookie, and the bridge could watch this cookie, and check for updates, based on it, much like how the receive-updated-views protocol works.
Of course it would be simpler to just have the UI for the progress and completion right inside the IFRAME itself, and not have to use the cookie trick. But there might be arbitrarily numerous changes to the UI, so that might not be feasible.
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion