Moving this discussion to the users list, since it will not make it into
2.3.
>>>>> On Fri, 23 Dec 2016 13:30:42 -0500, Leonardo Uribe <leonardo.uribe_at_irian.at> said:
LU> Thanks for accept this change.
LU> Since this is a new feature, the only change in the API or spec is add
LU> javax.faces.annotation.ResolveComponent annotation. I saw these
LU> two issues created in the issue tracker:
[...]
>>>>> On Thu, 19 Jan 2017 20:50:56 -0500, Leonardo Uribe <leonardo.uribe_at_irian.at> said:
LU> This is what JSF spec section 3.1.5 says about "binding":
LU> "... A component binding is a special value expression that can be used
LU> to facilitate "wiring up" a component instance to a corresponding property
LU> of a JavaBean that is associated with the page, and wants to manipulate
LU> component instances programatically. ..."
LU> Now, the objective of IoC or DI is provide a mechanism of injecting loosely
LU> coupled but type-safe components into an application.
[...]
LU> @ResolveComponent is nice because it enable developers to use JSF 2.3
LU> Search Expression API easily. The point of this API is help users to
LU> search components from a specific component reference. This is just
LU> another use case for it, where the "component reference" is given by
LU> the context. If you are calling the instance from an actionListener,
LU> the reference is the button, if you are validating something, the
LU> reference is the input component and so on.
LU> By these reasons, I consider @ResolveComponent a better solution than
LU> "binding" attribute to locate JSF component from CDI beans.
LU> But please note "binding" attribute is also used to provide an entry
LU> point to inject component instances created programmatically by the
LU> developer into a JSF component tree. That part is something not covered
LU> by @ResolveComponent, because the intention of @ResolveComponent is
LU> different. What happens here is "binding" attribute is something
LU> that is being used for the wrong reason. This attribute should be
LU> use only when the developer wants to provide the component instance
LU> programmatically. In that case, you don't want to add a proxy to the
LU> component instance, because it is the wrong place to do it.
TA> What about if the binding wouldn't set the component BUT creating a
TA> proxy for it?
[...]
LU> So, I'm not saying we can't fix "binding", I'm saying we cannot solve it at
LU> JSF spec level. But from a conceptual perspective, @ResolveComponent is
LU> the way to go if we want to take advantage of the power of CDI.
LU> But to be more specific, "binding" attribute is not a concept that
LU> is broken or something that needs to be fixed. Instead, it is
LU> something poorly understood, because it is not the right tool to
LU> locate components from CDI beans.
I like this idea.
>>>>> On Fri, 20 Jan 2017 10:35:50 +0100, arjan tijms <arjan.tijms_at_gmail.com> said:
AT> The CDI 2.0 EG was looking at an API for creating proxies. The full proxy
AT> factory wasn't standardises as far as I know, but they did realises a
AT> sub-case of it, namely the interceptor part:
AT>
http://docs.jboss.org/cdi/spec/2.0.Beta1/cdi-spec.html#interception_factory
AT> As for @ResolveComponent, if you want you could contribute this to
AT> OmniFaces (we use the Apache license), and then get some feedback from
AT> users about it. If given the opportunity again, we could then try to
AT> standardise this for JSF.next.
I hope you go that route.
>>>>> On Fri, 20 Jan 2017 10:27:02 -0500, Leonardo Uribe <leonardo.uribe_at_irian.at> said:
LU> But include it in the spec is the best option. This is the third time we
LU> try to fix this problem, and now is the first time we have an algorithm to
LU> fix it. This problem is the cause of most pain among new JSF developers,
LU> and I don't see how to improve @ResolveComponent further. This is it.
We'll see.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 2 business days until planned start of JSF 2.3 Public Review
| 22 business days until DevNexus 2017
| 47 business days until JavaLand 2017