[
https://issues.apache.org/jira/browse/MYFACES-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681211#comment-13681211
]
Leonardo Uribe commented on MYFACES-3716:
-----------------------------------------
I have committed partially the patch. I think there is a misunderstanting
between what should be done in decode() method and what should be done inside
encodeXXX().
I have analyzed the solution and I think we should create a wrapper class to
hold the real javax.servlet.http.Part, so when the component is saved into the
state, do not serialize the real Part instance, which by definition could or
not implement Serializable interface. The idea could be that the wrapper
implements StateHolder or Serializable interface/transient variable.
According to servlet spec 3.0 Part.write(...) method says this:
"... A convenience method to write an uploaded part to disk. The client code is
not concerned with whether or not the part is stored in memory, or on disk in a
temporary location. They just want to write the uploaded part to a file. This
method is not guaranteed to succeed if called more than once for the same part.
This allows a particular implementation to use, for example, file renaming,
where possible, rather than copying all of the underlying data, thus gaining a
significant performance benefit. ..."
It is expected that once the file is sent, it should be used and not saved
along with the tree. Other option is override submittedValue and value
attributes to prevent store them in the component state.
We should avoid override processRestoreState, because with the new algorithm
introduced in JSF 2.0, there is no warrant about if the method will be called
or not (a visit tree invocation do that job instead).
The code inside the renderer does not follow what the spec says. The idea is
check if the parent form has multipart encoding, not the incoming request,
which is different. But I'm still thinking about how this component will work
for ajax operations. I suppose the spec as is does not consider that, but I
suppose we should make it work.
> Implement h:inputFile
> ---------------------
>
> Key: MYFACES-3716
> URL: https://issues.apache.org/jira/browse/MYFACES-3716
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
> Reporter: Leonardo Uribe
> Attachments: inputfileCommentUpdated.patch, inputfileperfect.patch
>
>
> Implement h:inputFile as described in the spec
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
