[jsr-314-open] <h:dataTable> binding vs. ui:repeat

[Alexander Smirnov]

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