ui:repeat is a normal JSF component that supports binding but <c:forEach> is compilation directive only that has no component associated with tag. The question just recalls me one forgotten problem: h:dataTable and ui:repeat is complete different components that doing similar jobs. While ui:repeat knows about UIDataTable and works well inside it, DataTable itself has no clue what UIRepeat is iteration component, therefore rendering a set of tables using ui:repeat is not possible. On 08/03/2009 12:54 PM, Lincoln Baxter, III wrote: > So here's one of those, "why is this different than that?" questions: > > Unless I'm mistaken, ui:repeat is not a component and therefore cannot > be bound to a backing bean, but -- would it make sense to support > something *like* <h:dataTable> in order to support determining the > selected row on action events and value change events? A component that > would privide a bindable DataModel / List<Object> row access like > <h:dataTable>? > > *My use case is this:* > > * Managed Bean contains a List of objects > * Each object rendered to screen with input field > * User submits the input field (with a command link or button, etc) > * ManagedBean needs to take action on the appropriate row values > > > I have a list of objects - I need to render them onto the screen (not > necessarily in an HTML table, maybe a <ul> would be nicer) but I can't > use <ui:repeat> because each row has a commandLink, and I need to be > able to determine which row the user clicked on in order to take the > appropriate action. > > EL2 helps with this, but... now what if I have a ValueChangeEvent for an > input field on each <li> row? Now I can no longer use EL2 to pass the > row into the ValueChangeListener, and I would have to use something like > <f:setPropertyActionListener> which is not only getting increasingly > complicated, but I'd also have to set an attribute /inside/the VCL > itself, or in a bean VCL knows about - then referencing it - which is > terribly ugly. Now try to fit all that into a composite component and it > gets really ugly to try attaching tons of VCLs or ALs or SPALs to values > inside the component. > > Am I attacking this problem in the wrong way? Is this one of those > things that has an easy solution I'm not seeing? Or is this a genuine gap? > > --Lincoln > >