[JAVASERVERFACES_SPEC_PUBLIC-772] f:selectItems value="#{myMap}" underspecified Created: 17/Mar/10  Updated: 12/Aug/14

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File issue-772-test.patch    
Issue Links:
Related
is related to JAVASERVERFACES-1687 Renderers for UISelectMany don't supp... Closed
Issuezilla Id: 772
Status Whiteboard:

size_medium importance_large


 Description   

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.



 Comments   
Comment by Ed Burns [ 18/May/10 ]

This is important for 2.0 Rev a.

Comment by Ed Burns [ 24/May/10 ]

up to p2

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 24/May/10 ]

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

Comment by lu4242 [ 24/May/10 ]

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.

Comment by Ed Burns [ 27/May/10 ]

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

Comment by Ed Burns [ 27/May/10 ]

2.1.

Comment by lu4242 [ 28/May/10 ]

Ok, sounds reasonable let it for 2.1

Comment by Ed Burns [ 01/Jun/10 ]

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

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Generated at Mon Jul 06 09:43:49 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.