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