I have a <p:selectManyCheckbox>
inside <ui:repeat>
, getting it's items from a List of a certain Object Class (provided by <ui:repeat>
-variable) and is supposed to save the chosen items into another List of the same Object Class. But it calls the setter method #{cartBean.setSelectedExtras}
only for the last entry (last iteration of <ui:repeat>
).
<ui:repeat var="item" value="#{category.items}">
<p:selectManyCheckbox id="extraCheckbox" value="#{cartBean.selectedExtras}" layout="pageDirection" converter="omnifaces.SelectItemsConverter">
<f:selectItems value="#{item.items5}" var="extra" itemLabel="#{extra.name}"/>
</p:selectManyCheckbox>
</ui:repeat>
Update:
I changed the above construct just the way BalusC proposed.
Declaration in backing bean is now:
private List<List<Item>> selectedExtras = new ArrayList<List<Item>>();
When I check checkboxes that were created by the first loops of <ui:repeat>
and click the <p:commandButton>
inside the same <h:form>
the setter method of selectedExtras
is not called. When I check the checkboxes created in the last loop of <ui:repeat>
and click the <p:commandButton>
I get an Exception:
javax.el.PropertyNotFoundException: /lightbox-item.xhtml @57,165 value="#{cartBean.selectedExtras[iteration.index]}": null
This construct works fine for me.
As mentioned in among others the showcase page, the
omnifaces.SelectItemsConverter
uses by default thetoString()
representation of the complex object as converted item value. So if you didn't override thetoString()
method (so that it still defaults tocom.example.SomeClass@hashcode
which changes on every instantiation) and the#{item}
managed bean is request scoped, then the list would basically be changing on every HTTP request. This would cause a "Validation Error: Value is not valid" error.If you add
or
so that you get all (missing) validation/conversion messages in the UI, then you should have noticed it.
In order to utilize the
omnifaces.SelectItemsConverter
at its best, you should override thetoString()
method accordingly so that it returns a fixed and unique representation of the complex object. E.g.Alternatively, you could put the
#{item}
managed bean in a broader scope, such as the view scope.Update as to your update, you're binding the selected values of all checkboxgroups to one and same bean property
#{cartBean.selectedExtras}
. This way every iteration overrides the property with the values from the current iteration round as long as until you end up with the values of the last iteration. If you've placed a debug breakpoint on the setter, you'd have noticed that.This is not right. They should each point to a different bean property. Technically, you should have a
#{item.selectedExtras}
as property. But I think that this makes no sense in your current design. Better would be to make the#{cartBean.selectedExtras}
anList<Item[]>
orItem[][]
. This way you can get them to set based on the iteration index as follows:In case of
List<Item[]>
you only need to make sure that you preinitializeselectedExtras
with nulls as many times as there are#{category.items}
in bean's (post)constructor.In case of
Item[][]
, you can suffice with