Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-772
Type: Bug Bug
Status: Reopened Reopened
Priority: Critical Critical
Assignee: Unassigned
Reporter: lu4242
Votes: 2
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
javaserverfaces-spec-public

f:selectItems value="#{myMap}" underspecified

Created: 17/Mar/10 08:15 AM   Updated: 20/Dec/13 05:28 PM
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: 2.3

Time Tracking:
Not Specified

File Attachments: 1. Text File issue-772-test.patch (2 kB) 01/Jun/10 10:29 AM - Ed Burns

Environment:

Operating System: All
Platform: All

Issue Links:
Related
 

Issuezilla Id: 772
Status Whiteboard:

size_medium importance_large

Tags:
Participants: Ed Burns and lu4242


 Description  « Hide

The documentation of UISelectItems says:

Map - The keys of this object (once converted to Strings) are assumed to be
labels, and the values of this object (once converted to Strings) are assumed to
be values, of SelectItem instances that will be constructed dynamically and
added to the set of available options for the parent component, in the order
provided by an iterator over the keys.

This behavior comes from jsf 1.1, but in jsf 2.0 it was added some new
attributes (from f:selectItems tlddoc):

Version 2 of the specification introduces several new attributes, described
below. These are: var, itemValue, itemLabel, itemDescription, itemDisabled, and
itemLabelEscaped.

Now, what happen if some user do something like this:

<f:selectItems value="#{myMap}" var="item"
itemLabel="#{item.value.someLabelProperty}" itemValue="#{item.value}">

It just does not work, because there is no clear definition about what should
f:selectItems do in this case.

The proposal for solve this one is if var property is set and value implements
Map interface, use the entry object as var, so the user can choose between the
key and some attribute on the item value.



Ed Burns added a comment - 18/May/10 02:11 PM

This is important for 2.0 Rev a.


Ed Burns added a comment - 24/May/10 10:56 AM

up to p2


Ed Burns added a comment - 24/May/10 12:55 PM

take ownership.


Ed Burns added a comment - 24/May/10 04:14 PM

Leonardo, please re-open this if I am misunderstanding you.

The tlddoc for f:selectItems states that the "value" attribute may be any Collection or array. Map is
neither.

There is a related mojarra issue filed to track the fact that using Map as the type of the enclosing
UISelectMany's value is not working, though, as you point out, it should work.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1687


lu4242 added a comment - 24/May/10 04:56 PM

The documentation of f:selectItems and UISelectItems class is in fact different.
I'm taking into account the documentation of UISelectItems as the valid one.
Since f:selectItems creates a UISelectItems instance, the behavior implemented
is the one described on UISelectItems.

If you try to use something like this:

<f:selectItems value="#{someMap}"/>

it works since jsf 1.1.

I'll reopen it, because anyway it is necessary to update the documentation.


Ed Burns added a comment - 27/May/10 10:04 AM

Leonardo, we can either specify that the "var" attribute is unsupported for f:selectItems where value is
a Map, or we can push this to 2.1. I am constrained to these choice because to make "f:selectItems
var points to map" work needs a behavior change.

Your call.

Ed


Ed Burns added a comment - 27/May/10 10:10 AM

2.1.


lu4242 added a comment - 28/May/10 04:04 PM

Ok, sounds reasonable let it for 2.1


Ed Burns added a comment - 01/Jun/10 10:29 AM

Created an attachment (id=236)
patch showing this issue


Ed Burns added a comment - 08/Jun/10 01:10 PM

triage


Ed Burns added a comment - 24/Jun/10 02:41 PM

GlassFish 3.1 M6 at the latest.


Ed Burns added a comment - 10/Sep/10 01:31 PM

Move these to 2.2