Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      772
    • Status Whiteboard:
      Hide

      size_medium importance_large

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

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

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

          Show
          Ed Burns added a comment - Created an attachment (id=236) patch showing this issue
          Hide
          Ed Burns added a comment -

          triage

          Show
          Ed Burns added a comment - triage
          Hide
          Ed Burns added a comment -

          GlassFish 3.1 M6 at the latest.

          Show
          Ed Burns added a comment - GlassFish 3.1 M6 at the latest.
          Hide
          Ed Burns added a comment -

          Move these to 2.2

          Show
          Ed Burns added a comment - Move these to 2.2
          Hide
          Ed Burns added a comment -

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

          Show
          Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

            People

            • Assignee:
              Unassigned
              Reporter:
              lu4242
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: