jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: Improve UISelectMany to find Converter based on first non-null UISelectItem when type is java.util.Collection

From: Bauke Scholtz <balusc_at_gmail.com>
Date: Wed, 15 Jun 2016 11:24:44 +0200

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