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

[jsr372-experts] Re: [URGENT] _at_FacesDataModel inconsistencies with the spec (Re: Get your remaining items in)

From: Leonardo Uribe <leonardo.uribe_at_irian.at>
Date: Mon, 13 Feb 2017 20:59:02 -0500

Hi

LU> But in JSF, there is an Aplication class where you can register
Converter
LU> instances to apply for an specific "targetClass" and so on. But there is
LU> nothing for DataModel.

AT> It basically happens fully via CDI now. Either user provided with the
AT> @FacesDataModel annotation, or programmatically by adding your
AT> own annotated classes and/or Bean<T> instances using the CDI
AT> API (in an CDI extension).

The information available in this moment about @FacesDataModel is not
enough
to get the required information to create DataModel instances in a generic
way,
at least I can't imagine how to do it without store this info somewhere in
a implementation-specific way, and that's not what's required.

The point is there are many third party components that uses DataModel
abstraction to manipulate data, and it is necessary to provide an easy way
to
manipulate these "adapters". The algorithm that create/wrap an object into a
DataModel is always the same to every component using DataModel as an
abstraction to manipulate data, so why don't have just two methods in
Application class to encapsulate this logic in a generic way?.

This issue is critical, because the presence of @FacesDataModel force the
spec to describe how this "create-and-wrap" algorithm works, otherwise
third party components will not have the "recipe" to build DataModel
instances.

The more I think about this, the more convinced I'm on adding these
methods to Application class. Sorry to mention this issue at this point,
but I didn't notice the problem until I tried to implement it in MyFaces.

Regards,

Leonardo Uribe


2017-02-13 18:40 GMT-05:00 Leonardo Uribe <leonardo.uribe_at_irian.at>:

> Hi
>
> And the two methods proposed in Application class?
>
> public void addDataModel(Class<?> forClass, String dataModelClass)
> public DataModel createDataModel(java.lang.Class<?> forClass, Object
> value)
>
> I think that's the easiest way to fix it, because it standarize the way to
> access
> registered DataModel classes and encapsulate the algorithm that finds the
> right
> DataModel from a specified class.
>
> regards,
>
> Leonardo Uribe
>
> 2017-02-13 18:31 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
>
>> Hi,
>>
>> On Mon, Feb 13, 2017 at 11:35 PM, Leonardo Uribe <leonardo.uribe_at_irian.at
>> > wrote:
>>
>>> I have been checking the related documentation of @FacesDataModel and
>>> the
>>> unofficial explanation in:
>>>
>>> http://arjan-tijms.omnifaces.org/2015/07/jsf-23-new-feature-
>>> registrable.html
>>>
>>> The feature is ok from a functional perspective, it has sense,
>>>
>>
>> Good! :)
>>
>>
>>
>>> It means if UIData.getValue() has a value with type MyCollection, the
>>> value
>>> will be wrapped in a MyCollectionModel instance. This resembles
>>> "targetClass" for Converter instances.
>>>
>>
>> True, that kinda was the inspiration for the particular implementation of
>> this feature request.
>>
>>
>>
>>> But in JSF, there is an Aplication class where you can register Converter
>>> instances to apply for an specific "targetClass" and so on. But there is
>>> nothing for DataModel.
>>>
>>
>> It basically happens fully via CDI now. Either user provided with the
>> @FacesDataModel annotation, or programmatically by adding your own
>> annotated classes and/or Bean<T> instances using the CDI API (in an CDI
>> extension).
>>
>>
>>
>>> no new description in UIData.getDataModel(), nothing.
>>>
>>
>> That's a good point, I'll look at providing something of a description
>> there right away.
>>
>> Thanks again Leo!
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>