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