Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.6.1, 1.7DR#2
-
Fix Version/s: 1.7.1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All, Seam
-
Affects:Sample App./Tutorial
Description
Right now, if you want to use an ice:inputFile with an ice:outputProgress component, you have to use a lot of glue code in the bean, to hold the percent progress, and more importantly, to kickoff a render to show that progress.
Particularly the challenge is that, with Seam, while the pre-upload render in the main servlet has access to the PersistentFacesState for its rendering, the during-upload render in the UploadServer does not have access to it, which means that when the UploadServer calls the InputFile component, which calls the bean's progressListener, there's non-trivial code in the bean's progressListener that has to hold the PersistentFacesState from the pre-upload render, to use for the during-upload render.
We can remove all of that glue logic, if the InputFile does two things:
1. Grab the PersistentFacesState when it renders itself. Technically the InputFileRenderer handles this, but it actually delegates back to InputFile for rendering the IFRAME. Then, when setProgress(int) is called on the InputFile, is can invoke the progressListener, and simply initiate the render itself.
2. Add an attribute to the InputFile (called outputProgress?) that would have the outputProgress' id, so it can look it up, and simply call something like OutputProgress.setValue(this.getProgress()).
Now, the usage of #2 would be what sets off #1, since we don't want both the InputFile and any legacy bean progressListener code firing off a render. The contract of the outputProgress attribute would be that the application is asynchronous, and that the ice:outputProgress component is not trying to use a ValueBinding for its value attribute, and that any progressListener is not going to be using the renderManager.
One difference is that renderManager.requestRender seems to be doing a bit more than just PersistentFacesState.execute() then render(). So that should be looked into.
Particularly the challenge is that, with Seam, while the pre-upload render in the main servlet has access to the PersistentFacesState for its rendering, the during-upload render in the UploadServer does not have access to it, which means that when the UploadServer calls the InputFile component, which calls the bean's progressListener, there's non-trivial code in the bean's progressListener that has to hold the PersistentFacesState from the pre-upload render, to use for the during-upload render.
We can remove all of that glue logic, if the InputFile does two things:
1. Grab the PersistentFacesState when it renders itself. Technically the InputFileRenderer handles this, but it actually delegates back to InputFile for rendering the IFRAME. Then, when setProgress(int) is called on the InputFile, is can invoke the progressListener, and simply initiate the render itself.
2. Add an attribute to the InputFile (called outputProgress?) that would have the outputProgress' id, so it can look it up, and simply call something like OutputProgress.setValue(this.getProgress()).
Now, the usage of #2 would be what sets off #1, since we don't want both the InputFile and any legacy bean progressListener code firing off a render. The contract of the outputProgress attribute would be that the application is asynchronous, and that the ice:outputProgress component is not trying to use a ValueBinding for its value attribute, and that any progressListener is not going to be using the renderManager.
One difference is that renderManager.requestRender seems to be doing a bit more than just PersistentFacesState.execute() then render(). So that should be looked into.
Activity
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Assignee | Mark Collette [ mark.collette ] |
| Issue Type | New Feature [ 2 ] | Improvement [ 4 ] |
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Fix Version/s | 1.7.1 [ 10122 ] | |
| Affects | [Sample App./Tutorial] | |
| Resolution | Fixed [ 1 ] | |
| Assignee | Mark Collette [ mark.collette ] |
An alternative syntax:
<ice:inputFile id="fileUpload" actionListener="#
{inputFile.action}" />
<ice:outputProgress for="fileUpload" pushprogress="10" />
In general we can expect a source of progress events to produce more events than should be pushed to the client. For instance, it would be reasonable for inputFile to issue a progress event every time a write occurred to the file system.
Show
Ted Goddard
added a comment -
An alternative syntax:
<ice:inputFile id="fileUpload" actionListener="#
{inputFile.action}
" />
<ice:outputProgress for="fileUpload" pushprogress="10" />
In general we can expect a source of progress events to produce more events than should be pushed to the client. For instance, it would be reasonable for inputFile to issue a progress event every time a write occurred to the file system.
Historically, when the inputFile's current file upload was progressing, and the progressListener was invoked, the progressListener's bean would implement com.icesoft.faces.async.render.Renderable, and use the com.icesoft.faces.async.render.RenderManager in conjunction with the com.icesoft.faces.async.render.OnDemandRenderer, to do a server push, to update the view in the browser with the current progress.
But now, you can just set progressRender="true" on the inputFile, and the server push will happen for you, without setting up all that glue code in the bean. You still have to set your outputProgress component's progress percent in the bean via the progressListener, and you have to enabled asynchronous mode, by setting the com.icesoft.faces.synchronousUpdate context parameter to false.
Our component-showcase example has been updated to use the new simplified technique, but I haven't changed the Seam component-showcase.
TRUNK
Subversion 16770
icefaces\component-metadata\src\main\resources\conf\ice_cust_properties\cust-inputFile-props.xml
icefaces\component\src\com\icesoft\faces\component\inputfile\InputFile.java
icefaces\core\src\com\icesoft\faces\component\FileUploadComponent.java
icefaces\core\src\com\icesoft\faces\webapp\http\core\UploadServer.java
icefaces\core\src\com\icesoft\faces\webapp\xmlhttp\PersistentFacesState.java
icefaces\samples\component-showcase\common-src\org\icefaces\application\showcase\view\bean\examples\component\inputFile\InputFileController.java
icefaces\samples\component-showcase\common-src\org\icefaces\application\showcase\view\bean\examples\component\inputFile\InputFileData.java
icefaces\samples\component-showcase\common-web\WEB-INF\faces-config-example-beans.xml
icefaces\samples\component-showcase\common-web\WEB-INF\includes\examples\custom\inputFile.jspx
ICEfaces 1.7 branch
Subversion 16773
icefaces\component-metadata\src\main\resources\conf\ice_cust_properties\cust-inputFile-props.xml
icefaces\component\src\com\icesoft\faces\component\inputfile\InputFile.java
icefaces\core\src\com\icesoft\faces\component\FileUploadComponent.java
icefaces\core\src\com\icesoft\faces\webapp\http\core\UploadServer.java
icefaces\core\src\com\icesoft\faces\webapp\xmlhttp\PersistentFacesState.java
icefaces\samples\component-showcase\common-src\org\icefaces\application\showcase\view\bean\examples\component\inputFile\InputFileController.java
icefaces\samples\component-showcase\common-src\org\icefaces\application\showcase\view\bean\examples\component\inputFile\InputFileData.java
icefaces\samples\component-showcase\common-web\WEB-INF\faces-config-example-beans.xml
icefaces\samples\component-showcase\common-web\WEB-INF\includes\examples\custom\inputFile.jspx