jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [PROPOSAL] CDI integration for UIComponent instances in JSF 2.3

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Fri, 20 Jan 2017 10:35:50 +0100

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.

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.



> 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


> 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.

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
>>>
>>
>>
>