+1 to checking custom first and making it the default behavior....less
configuration is better.
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Wed, Jun 10, 2015 at 10:15 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Wed, Jun 10, 2015 at 3:20 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
>
>> Only people who are using JSF 2.3 will be using this annotation, right?
>
>
> Basically yes. But I was half thinking about people running their JSF 2.2
> application on a Java EE 8 server and using a library that may contain this
> new annotation as a default for some type.
>
>
>
>> So I say we check custom ones first and make that the default behavior.
>
>
> If this was an OmniFaces feature there would be no doubt in my mind to
> check custom ones first, so functionality wise I agree with this ;)
>
> I was just being extra careful with backwards compatibility, as from
> previous discussions here I more or less picked up the signal that
> backwards compatibility is the single most important consideration. But
> maybe there isn't really an issue to begin with. So if we all, and
> specifically the spec leads, agree to do custom checks first I'd be more
> than happy to change this.
>
>
>
>> Maybe provide a switch, but don't tie it to the version number.
>
>
> Well, I was contemplating if it's wise or not to tie in to the existing
> (in JSF 2.3) javax.faces.ENABLE_CDI_RESOLVER_CHAIN switch.
>
> See
> https://github.com/omnifaces/mojarra/commit/6dd5dd1b4095cc8dbec62021ba948379aa4b51bd
>
> I specifically wonder what Manfred thinks about this, as he introduced
> this switch.
>
> Kind regards,
> Arjan Tijms
>
>
>
>>
>>
>> On Wednesday, June 10, 2015, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>
>>> Hi,
>>>
>>> On Wed, Jun 10, 2015 at 2:42 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
>>>
>>>> I didn't review the code, but one thing I wonder about is the inability
>>>> to register a custom DataModel for types like List. That is a pretty common
>>>> use case.
>>>
>>>
>>> Yes, this is a design decision we as an EG have to make. Maybe there's
>>> even some compromise possible. E.g. using the same 2.3 switch that's used
>>> for CDI resolving to activate this feature, and then when activated in "2.3
>>> mode" do give it the ability to override List and such. Implementation of
>>> that is trivial (just move the check up in the list)
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> On Wednesday, June 10, 2015, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Just wondering, anyone has any feedback on the changebundle?
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jun 7, 2015 at 11:45 PM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>> I just attached the changebundle for this at:
>>>>>> https://java.net/jira/secure/attachment/54975/changebundle.txt
>>>>>>
>>>>>> The main and only addition to the public API is the annotation
>>>>>> @FacesDataModel that when applied to a user provided DataModel registers it
>>>>>> with the runtime. Via an attribute it declares the class it's able to wrap.
>>>>>>
>>>>>> As for the Implementation, those classes are collected
>>>>>> in CdiExtension#processBean
>>>>>>
>>>>>> After the collecting phase the collected classes are sorted in
>>>>>> CdiExtension#processBean such that if an instance of any class from
>>>>>> the collection would be a subtype of any other class in that collection, it
>>>>>> has to appear before it. Apart from this constraint the order does not
>>>>>> matter.
>>>>>>
>>>>>> This sorting allows a sequential scan through the collection to find
>>>>>> the best matching type. E.g. suppose the collection would contain
>>>>>> List.class and Collection.class, then List.class would appear before
>>>>>> Collection.class. Given an instance of ArrayList, List would match before
>>>>>> Collection.
>>>>>>
>>>>>> The resulting collection is then made available via CDI in
>>>>>> application scope, albeit via an implementation specific name. For Mojarra
>>>>>> I choose "comSunFacesDataModelClassesMap" for this name.
>>>>>>
>>>>>> Finally UIData obtains said collection via CDI and does a
>>>>>> filter/findFirst on it checking if the object for which a DataModel wrapper
>>>>>> needs to be found is assignable to the type that each DataModel declared to
>>>>>> be able to handle. As explained above, the first match is the best batch.
>>>>>>
>>>>>> One design decision was to have the custom DataModel check to be done
>>>>>> *after* all existing checks for wrappers are done (e.g. the hardcoded
>>>>>> checks for List, Collection, Iterable, etc). This means that a custom
>>>>>> DataModel cannot override those types. This was done to ensure maximum
>>>>>> backwards compatibility, although one could argue it's more powerful to
>>>>>> check for the custom DataModels first.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 3, 2015 at 1:04 AM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi y'all,
>>>>>>>
>>>>>>> Just some quick update on this. After a small hiatus I returned to
>>>>>>> this issue and started implementing it. There were a few small challenges
>>>>>>> that made this issue a bit more difficult than initially anticipated.
>>>>>>>
>>>>>>> Specifically the fact that registering a DataModel for say
>>>>>>> java.util.List requires some clever matching of class types, as the runtime
>>>>>>> object encountered can be e.g. an ArrayList or whatever sub type, and the
>>>>>>> "whatever sub type" can have a chain of super classes and a tree of
>>>>>>> interfaces and their super interfaces, where each super class can also have
>>>>>>> its own tree of interfaces and their super interfaces.
>>>>>>>
>>>>>>> A small hindrance is also that UIData (of course) contains
>>>>>>> implementation code, but it's in the API project of Mojarra which
>>>>>>> can't/doesn't have utility classes. So UIData and UIRepeat can't share
>>>>>>> between each other directly, nor can either of them use a utility class
>>>>>>> from the impl. project.
>>>>>>>
>>>>>>> Nevertheless I'm making good progress and hope to present a
>>>>>>> changebundle for evaluation soon.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Arjan Tijms
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 10, 2015 at 9:17 AM, Hanspeter <hampidu_at_gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Hanspeter
>>>>>>>> Am 09.03.2015 20:41 schrieb "Frank Caputo" <frank_at_frankcaputo.de>:
>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> Ciao Frank
>>>>>>>>>
>>>>>>>>> Am 09.03.2015 um 17:31 schrieb Bauke Scholtz <balusc_at_gmail.com>:
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> Cheers, B
>>>>>>>>>
>>>>>>>>> On Sun, Mar 8, 2015 at 11:22 PM, arjan tijms <
>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> As the third part of extending the data model wrappers for UIData
>>>>>>>>>> and
>>>>>>>>>> UIRepeat, it was suggested to make data model wrappers
>>>>>>>>>> registrable by
>>>>>>>>>> the user. Issue JAVASERVERFACES_SPEC_PUBLIC-1078 was created for
>>>>>>>>>> this,
>>>>>>>>>> but it was also mentioned as part of
>>>>>>>>>> JAVASERVERFACES_SPEC_PUBLIC-1103.
>>>>>>>>>>
>>>>>>>>>> I took a quick look, and now with CDI available it seems almost
>>>>>>>>>> trivial to implement this.
>>>>>>>>>>
>>>>>>>>>> JSF would provide a CDI qualifier annotation like:
>>>>>>>>>>
>>>>>>>>>> @Retention(RUNTIME)
>>>>>>>>>> @Target(TYPE)
>>>>>>>>>> @Inherited
>>>>>>>>>> @Qualifier
>>>>>>>>>> public @interface FacesDataModel {
>>>>>>>>>> Class<?> forClass();
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The user then provides something like the following:
>>>>>>>>>>
>>>>>>>>>> @FacesDataModel(forClass=MyObject.class)
>>>>>>>>>> public class MyDataModel<E> extends DataModel<E> {
>>>>>>>>>> // datamodel methods
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The runtime then looks up an instance of that via CDI (just like
>>>>>>>>>> happens now for CD Converters and Validators, which is almost a
>>>>>>>>>> one-liner in Manfred's CDIUtils).
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Arjan Tijms
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> ___
>>>>
>>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>>>> consulting
>>>> http://www.JSFCentral.com | @jsfcentral
>>>> +1 203-998-0403
>>>>
>>>> * Listen to the Enterprise Java Newscast: *http://
>>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>>> <http://ww.enterprisejavanews.com>*
>>>> * JSFCentral Interviews Podcast:
>>>> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>>>> * Sign up for the JSFCentral Newsletter:
>>>> http://oi.vresp.com/?fid=ac048d0e17
>>>>
>>>>
>>>
>>
>> --
>> ___
>>
>> Kito D. Mann | @kito99 | Author, JSF in Action
>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>> consulting
>> http://www.JSFCentral.com | @jsfcentral
>> +1 203-998-0403
>>
>> * Listen to the Enterprise Java Newscast: *http://
>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>> <http://ww.enterprisejavanews.com>*
>> * JSFCentral Interviews Podcast:
>> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>> * Sign up for the JSFCentral Newsletter:
>> http://oi.vresp.com/?fid=ac048d0e17
>>
>>
>