myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Commented] (MYFACES-3716) Implement h:inputFile
Date Wed, 12 Jun 2013 13:27:20 GMT

    [ 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

Mime
View raw message