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.
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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','hampidu_at_gmail.com');>> wrote:
>>>
>>>> +1
>>>>
>>>> Hanspeter
>>>> Am 09.03.2015 20:41 schrieb "Frank Caputo" <frank_at_frankcaputo.de
>>>> <javascript:_e(%7B%7D,'cvml','frank_at_frankcaputo.de');>>:
>>>>
>>>>> +1
>>>>>
>>>>> Ciao Frank
>>>>>
>>>>> Am 09.03.2015 um 17:31 schrieb Bauke Scholtz <balusc_at_gmail.com
>>>>> <javascript:_e(%7B%7D,'cvml','balusc_at_gmail.com');>>:
>>>>>
>>>>> +1
>>>>>
>>>>> Cheers, B
>>>>>
>>>>> On Sun, Mar 8, 2015 at 11:22 PM, arjan tijms <arjan.tijms_at_gmail.com
>>>>> <javascript:_e(%7B%7D,'cvml','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