[
https://issues.apache.org/jira/browse/MYFACES-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13788512#comment-13788512
]
Leonardo Uribe commented on MYFACES-3797:
-----------------------------------------
I think the best way to analyze the advantages or disadvantages is to try to
forecast the future a bit.
Suppose you have a custom input component that does not extend from
UIComponentBase but from UIComponent and you need to write the state saving
logic. What do you do? you read the spec, and make custom implementations based
on the descriptions there. But you haven't realized that small detail done
inside UIComponentBase or DeltaStateHelper, that has changed the behavior of a
method that has a clear description in the spec javadoc. At the end, your code
will not work, because from outside you don't know what's inside myfaces code.
And the solution? do some ugly myfaces specific hack that only god knows how to
do in your third party code and you'll pray that on further versions it will
not get broken.
On the other side, the solution using an adapter just introduce a fine layer
between the converter validator implementation and the component tree, that
will be added only in those cases where CDI injection is required, so by
default it is disabled. Using FacesWrapper, we can always get the inner
instance. Will the existing code keep working? Yes, of course, remember the
wrapper is optional. Now the question is which third party libraries do a type
check over the new converter / validator instances that are injected. But more
important than that is just using the spec, the third party developer can do
the necessary code to inspect the wrapper and check the type correctly. In
fact, the code is just trivial.
Do we care about existing 3rd party libs for a new feature to be added in
MyFaces 2.2.x and that by default is disabled? Absolutely no. That's a load
that we don't require to carry on. JSF 2.2 is a major release, it is reasonable
to write 2.2 versions of the libraries affected, but remember FacesWrapper is
there since 2.0, so the necessary code can be added in 2.0 branches as well.
In this case, we have a solution that just breaks encapsulation principle
(which means you don't need to know what's inside the code to make it work
together) against another (using an adapter) that does not.
Now the state problem. To be clear, with a wrapper we don't add state. How is
that possible? You can make the wrapper implement PartialStateHolder and with
that the problem is solved. I know that, because there are some examples inside
MyFaces Core that do precisely that. Write the wrapper can be tricky, but it
will work, no doubt about that in my mind.
The solution using the adapter could be discussed and included in the spec.
Inclusive, we can make an SPI interface for this one. What's the deal about the
adapter solution? there is no problem, it is feasible and its drawbacks are
minimal compared with the alternative.
> 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_2.patch, 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)
