Thanks for your work...great enhancement!
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Thu, Jun 23, 2016 at 1:15 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> 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
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>