Only people who are using JSF 2.3 will be using this annotation, right? So
I say we check custom ones first and make that the default behavior. Maybe
provide a switch, but don't tie it to the version number.
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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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