Hi
AT> But I'm afraid it's, unfortunately, simply too late now.
@Ed, Manfred: WDYT? a public review where you send feedback before 30 days
and is it too late? why bother to send a public review if changes will not
be accepted?
regards,
Leonardo Uribe
2017-02-14 14:14 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
> Hi,
>
> On Tuesday, February 14, 2017, Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>
>> Hi
>>
>> The problem here is there are other components that does not extend from
>> UIData and uses DataModel.
>>
>
> I'm absolutely aware of the necessity and the use case ;)
>
> But in my example the component that needs the DataModel instance doesn't
> have to extend from UIData. Using the trick I mentioned you can instantiate
> a separate UIData instance, then do the setValue/getDataModel trick on it.
>
>
>> The closest example is UIRepeat, but there are others too.
>>
>
> UIRepeat should already support it as well, but the issue is of course
> components from third party libraries that don't extend from either UIData
> or UIRepeat.
>
> Those can use the trick I mentioned though. Not ideal I know, but should
> work for now.
>
>
>
>> 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?
>>
>
> I personally can't authorise anything, as I'm just a regular EG member
> like you are. Only Ed can possibly allow this at this point.
>
> But I'm afraid it's, unfortunately, simply too late now.
>
> Kind regards,
> Arjan Tijms
>
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>