Hi
The problem here is there are other components that does not extend from
UIData and uses DataModel. The closest example is UIRepeat, but there are
others too.
The important thing is provide something somewhere that can be commonly
accessed. For example, we could use a map or some generic interface stored
in externalContext.getApplicationMap(). It that way, we can avoid add
methods, but we provide what we need just agreeing with the name and what
does it return. It is not perfect but it is something at least. Is this
possible alternative feasible?
regards,
Leonardo Uribe
2017-02-14 11:41 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
> Hi Leo,
>
> On Tue, Feb 14, 2017 at 12:40 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>
>> 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)
>>
>
> The functionality for addDataModel at least is handled by CDI. That can't
> be done by such a method, since it has to be done in the CDI extension and
> the JSF Application class is not necessarily available by then. The other
> way around, when the Application class is available it's too late for CDI
> to accept new Bean<T> registrations, let alone annotated types.
>
> The createDataModel method is practically there already, it's in Mojarra:
>
> private DataModel<?> createDataModel(final Class<?> forClass)
>
> I would love to have added this method somewhere publicly, but I'm afraid
> it's now too late for that :(
>
> What you CAN do however, is subclass UIData, then instantiate that. Then do
>
> myUIData.setValue(someClassInstance);
> UIDataModel<?> myModel = myUIData.getDataModel();
>
> That should guaranteed give you the right DataModel instance. If it's
> covered by an existing known type it will return the wrapper for that,
> otherwise the CDI version will be called.
>
> I humbly apologise for my oversight of adding that method at a public
> place before. This is indeed my mistake. I will update the JavaDoc as you
> requested to clarify this usage. For the next spec cycle we could add a
> more convenient mechanism at the earliest opportunity.
>
> Once again my apologies and thanks for finding this.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>> 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
>>>
>>>
>>>
>>>
>>
>