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-3797) cdi support for converters and validators
Date Mon, 07 Oct 2013 10:23:42 GMT

    [ https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788047#comment-13788047
] 

Leonardo Uribe commented on MYFACES-3797:
-----------------------------------------

#1
The patch adds some specific code inside, changing the default behavior of the state handling
algorithm. But what happen if the user implements directly a class from UIComponent (for example
Trinidad and other jsf libraries)? all that code could be just ignored. Include that code
also has performance considerations, because most of the time it makes unnecessary checks.
The nice part about delegation pattern in this part is you can encapsulate the code that do
the injection or whatever in just one place and the "adapter" will deal with the state issues
(if is serializable, if is stateholder, whatever). The idea is attach a "proxy" on the component
tree that deal with CDI logic in those cases where the converter or validator uses CDI injection.

#2
It becomes an issue when you think about pss algorithm. Where a serializable converter should
be stored? it the view scope? why there is an CDI storage for something that should be "serializable"?
now the view state is split in two: one managed by jsf, the other in some cdi bag. I can see
it could work, but we need to do some tests first to be sure how to deal with this part. 

#3
"converter/validator is StateHolder/PartialStateHolder" That's not necessary true. A converter
validator can be just a normal class, serializable, stateholder or partialstateholder. The
code that deals with that logic is in UIOutput/UIInput. The real question is which is the
default lifecycle for a converter/validator in each case. In theory it should be request scope,
but maybe it is less than request scope.  But if implements StateHolder it should be view
scope. I don't remember issues over the current implementation of view scope. Remember view
scope is a passivation capable scope, so all beans should implement Serializable.

#4
What will be attached to the component tree? a proxy or the real instance? I have never tried
that, so I don't have idea about how the code works in that part. 

In conclusion, my doubts are more related about the interactions between the state management
and cdi and the aplicability of the solution for third party libraries, even if I know the
proposed patch could work.

> cdi support for converters and validators
> -----------------------------------------
>
>                 Key: MYFACES-3797
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3797
>             Project: MyFaces Core
>          Issue Type: New Feature
>          Components: JSR-344
>            Reporter: Gerhard Petracek
>            Assignee: Gerhard Petracek
>         Attachments: MYFACES-3797.patch
>
>
> with
>     <context-param>
>         <param-name>org.apache.myfaces.CONVERTER_INJECTION_ENABLED</param-name>
>         <param-value>true</param-value>
>     </context-param>
> and
>     <context-param>
>         <param-name>org.apache.myfaces.VALIDATOR_INJECTION_ENABLED</param-name>
>         <param-value>true</param-value>
>     </context-param>
> it should be possible to enable cdi support for converters/validators.
> we need the config, because it was postponed for the spec.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message