Hi
2017-01-20 4:35 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
> Hi,
>
> On Fri, Jan 20, 2017 at 2:50 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>
>> By these reasons, I consider @ResolveComponent a better solution than
>> "binding" attribute to locate JSF component from CDI beans.
>>
>
> Absolutely, I agree with that fully.
>
>
>> But please note "binding" attribute is also used to provide an entry
>> point to inject component instances created programmatically by the
>> developer into a JSF component tree.
>>
>
> True, this is a somewhat different story indeed, but the "binding"
> attribute is now used for both. Another option I investigated to inject
> component instances into the tree is to throw a (CDI) event right after the
> component tree is created. A CDI backing bean can listen to that event,
> then use the search API (if needed) to locate the right spot and inject the
> component into the tree.
>
>
It could be. In fact, "binding" attribute looks more like a "Producer" in
CDI. But the VDL is the expert to create component trees, not CDI, so I
still prefer "binding" attribute for that function.
> Even with that the "binding" attribute would still be useful when you want
> to mark the exact point in the tree from the page itself, but with such
> event the need for it would be less I think.
>
>
Yes, I agree. If you want to mark a point where you need to include a
component programmatically, "binding" attribute is great because you also
define the component type and id.
>
>
>> The technical reason is the solution needs all JSF component classes to
>> create the necessary CDI producers at CDI startup. You can't register CDI
>> producers dynamically. It can be done using an API provided by
>> openwebbeans
>> but that's not CDI standard.
>>
>
> The CDI 2.0 EG was looking at an API for creating proxies. The full proxy
> factory wasn't standardises as far as I know, but they did realises a
> sub-case of it, namely the interceptor part: http://docs.jboss.org/
> cdi/spec/2.0.Beta1/cdi-spec.html#interception_factory
>
>
Ok, good to know that.
> But to be more specific, "binding" attribute is not a concept that is
>> broken
>> or something that needs to be fixed. Instead, it is something poorly
>> understood, because it is not the right tool to locate components from CDI
>> beans.
>>
>
> Yes, indeed.
>
> As for @ResolveComponent, if you want you could contribute this to
> OmniFaces (we use the Apache license), and then get some feedback from
> users about it. If given the opportunity again, we could then try to
> standardise this for JSF.next.
>
>
I think this code has life on its own. It could be a module in MyFaces
Commons, which is a neutral zone to include libraries that can live in JSF
apps without worry about third party library incompatibilities.
But include it in the spec is the best option. This is the third time we
try to fix this problem, and now is the first time we have an algorithm to
fix it. This problem is the cause of most pain among new JSF developers,
and I don't see how to improve @ResolveComponent further. This is it.
regards,
Leonardo Uribe
> Kind regards,
> Arjan Tijms
>
>
>
>>
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2017-01-11 14:29 GMT-05:00 Leonardo Uribe <leonardo.uribe_at_irian.at>:
>>
>>> Hi
>>>
>>> Thanks Ed for review this.
>>>
>>> LU> In few words...
>>>
>>> EB> Ahh, it's been far too long since I've seen a mail with your famous
>>> EB> introduction "In few words..."! Thanks for spelling it out.
>>>
>>> Jejeje. Someday I will learn to write short emails. Jejeje
>>>
>>> EB>> I hope so too, but Manfred and I reserve judgement on this and other
>>> EB>> features at this point.
>>>
>>> Yes, of course. I understand the restrictions we have. I just work
>>> hoping for the best, but I understand not all proposals should pass.
>>>
>>> In my opinion, @ResolveComponent can live as an extension since the
>>> changes in UIComponent were already done (remove final modifiers from
>>> methods). Search Expression API is very mature at this point, it has been
>>> already tested in PrimeFaces with good opinions, and it standarize
>>> something that is loosely mentioned in the spec (JSF 2.2 section 14.2.2).
>>> Let's see what happens.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2017-01-11 11:39 GMT-05:00 Edward Burns <edward.burns_at_oracle.com>:
>>>
>>>> >>>>> On Wed, 21 Dec 2016 19:10:45 -0500, Leonardo Uribe <
>>>> leonardo.uribe_at_irian.at> said:
>>>>
>>>> LU> Hi
>>>> LU> I have some good news to tell.
>>>>
>>>> LU> After some attempts and using Arjan trick in Omnifaces, and based
>>>> on the
>>>> LU> previous discussion I was able to code a consistent solution using a
>>>> LU> CDI centric approach. I made this example work:
>>>>
>>>> [...]
>>>>
>>>> >>>>> On Fri, 23 Dec 2016 13:30:42 -0500, Leonardo Uribe <
>>>> leonardo.uribe_at_irian.at> said:
>>>>
>>>> LU> Hi Manfred
>>>> LU> Thanks for accept this change.
>>>>
>>>> I need to remind you that this is not an acceptance of the change. It
>>>> is an acceptance to consider the change. We are pretty much in lockdown
>>>> mode, and this feature does look like it might have the potential to
>>>> destabilize. Nonetheless, here in JSF we have always been very open to
>>>> community contribution so I promise a good hearing.
>>>>
>>>> [...]
>>>>
>>>> LU> The other option is ask Thomas Andraschko to include this,
>>>> LU> since he is working to include Search Expression API, which is
>>>> LU> related to this issue (that algorithm resolves the expression
>>>> LU> in @ResolveComponent, so this is another use case for that API).
>>>>
>>>> I reviewed Thomas's work on Monday and found it quite solid. He
>>>> responded to my request for revision on all the points. I will review
>>>> his further thanges today.
>>>>
>>>> LU> @Thomas: have you already committed the changes proposed
>>>> LU> for Search Expression API in Mojarra or it is still work in
>>>> LU> progress?
>>>>
>>>> No, it has not been committed, or even accepted to be committed. It's
>>>> still under review.
>>>>
>>>> >>>>> On Mon, 28 Nov 2016 07:08:13 -0500, Kito Mann <
>>>> kito.mann_at_virtua.com> said:
>>>>
>>>> KM> Leonardo, this looks awesome. One question, though: what about
>>>> wildcard /
>>>> KM> partial id matching? I'm surprised that is missing.
>>>>
>>>> >>>>> On Tue, 29 Nov 2016 01:12:12 -0500, Leonardo Uribe <
>>>> leonardo.uribe_at_irian.at> said:
>>>>
>>>> LU> The current proposal does not have it.
>>>>
>>>> Let's leave that out of the current iteration.
>>>>
>>>> >>>>> On Thu, 1 Dec 2016 02:11:30 -0500, Leonardo Uribe <
>>>> leonardo.uribe_at_irian.at> said:
>>>>
>>>> LU> In few words...
>>>>
>>>> Ahh, it's been far too long since I've seen a mail with your famous
>>>> introduction "In few words..."! Thanks for spelling it out.
>>>>
>>>> [...]
>>>>
>>>> LU> in Primefaces. But we need other examples to justify the "wildcard"
>>>> case
>>>> LU> proposed by Bootsfaces, because what I have seen so far is @id(...)
>>>> without
>>>> LU> wilcards is good enough. Maybe extend @id to receive multiple ids.
>>>>
>>>> Yes, I'd like to leave wildcards out for now.
>>>>
>>>> >>>>> On Sun, 8 Jan 2017 13:06:51 +0100, Bauke Scholtz <
>>>> balusc_at_gmail.com> said:
>>>>
>>>> B> In spite of the comments, which are mainly quality and technical
>>>> related,
>>>> B> the API itself looks good! Hopefully this will get into 2.3.
>>>>
>>>> I hope so too, but Manfred and I reserve judgement on this and other
>>>> features at this point.
>>>>
>>>> Thanks,
>>>>
>>>> Ed
>>>>
>>>> --
>>>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>>>> | 8 business days until planned start of JSF 2.3 Public Review
>>>> | 28 business days until DevNexus 2017
>>>> | 53 business days until JavaLand 2017
>>>>
>>>
>>>
>>
>