I have for now implemented as above. See
https://java.net/jira/plugins/servlet/mobile#issue/JAVASERVERFACES_SPEC_PUBLIC-1422
Cheers, B
On Wed, Jun 15, 2016, 11:24 Bauke Scholtz <balusc_at_gmail.com> wrote:
> Another improvement, but perhaps a bit too expensive on large lists, but
> it's not that different during render response, is the following:
>
> - Convert non-null select item object to string the usual way (as done
> during render response).
> - Compare its string output with submitted value.
> - If match, add that select item object to list (no string-object
> conversion needed).
>
> What do you think?
>
> Cheers, B
>
> On Tue, Jun 14, 2016 at 9:41 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>
>> In hindsight, it's more robust to specify UISelectMany with Collection as
>> below:
>>
>> * <li class="changed_added_2_0"><p>A <code>java.util.Collection</code>.
>> * <span class="changed_modified_2_3">If all non-<code>null</code> item
>> values
>> * of provided set of available options have the same element type, then
>> look up the
>> * registered by-class {_at_link javax.faces.convert.Converter} for the common
>> * element type.</span></p></li>
>>
>> This should prevent existing applications from breaking when the enduser
>> for some reason has a Collection<Object> with different types as available
>> items and is (incorrectly) relying on the submitted values being a "plain"
>> Collection<String>.
>>
>> I will make changes tomorrow.
>>
>> Cheers, B
>>
>>
>> On Tue, Jun 14, 2016 at 4:02 PM, Josh Juneau <juneau001_at_gmail.com> wrote:
>>
>>> Excellent...great enhancement...sorry for my tardy +1!
>>>
>>> Thanks Bauke
>>>
>>> Josh Juneau
>>> juneau001_at_gmail.com
>>> http://jj-blogger.blogspot.com
>>> https://www.apress.com/index.php/author/author/view/id/1866
>>>
>>>
>>> On Tue, Jun 14, 2016 at 6:56 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>>>
>>>> It has been implemented
>>>> https://java.net/projects/mojarra/sources/git/revision/8f102043307e371056f4cbb983a2b5caf620ef1f
>>>>
>>>> On Mon, Jun 13, 2016 at 9:09 PM, Neil Griffin <
>>>> neil.griffin_at_portletfaces.org> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> This restriction probably dates back to the days of JSF 1.0/1.1 and
>>>>> Java SE 1.4 before java.util.Collection had type enforcement via generics.
>>>>>
>>>>> > On Jun 13, 2016, at 3:04 AM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > +1
>>>>> >
>>>>> > No objection, sounds like a good idea. Especially since MyFaces
>>>>> implemented it already I almost assume a default +1 by them (but would be
>>>>> good to see it explicitly here ;)).
>>>>> >
>>>>> > Kind regards,
>>>>> > Arjan Tijms
>>>>> >
>>>>> >
>>>>> > On Sat, Jun 11, 2016 at 9:56 AM, Bauke Scholtz <balusc_at_gmail.com>
>>>>> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > See https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1422.
>>>>> >
>>>>> > Currently,
>>>>> http://docs.oracle.com/javaee/7/api/javax/faces/component/UISelectMany.html
>>>>> states that it won't make any attempt to obtain the converter when the
>>>>> value is of type java.util.Collection.
>>>>> > It is technically however possible to obtain it anyway by inspecting
>>>>> the first non-null select item. MyFaces has this already implemented and I
>>>>> find it's a good idea to improve the spec accordingly.
>>>>> > This should save the effort of explicitly declaring the converter by
>>>>> name and rely on forClass.
>>>>> > If there are no objections, I will take care of it for 2.3.
>>>>> > Cheers, B
>>>>> >
>>>>>
>>>>>
>>>>
>>>
>>
>