All the bling in the world can't save scrollable data tables

[peterjca]

I've wasted a week of my life trying to get the scrollable data table working. There's no point in having a table dripping in bling if you can't find out what row has been selected. Ajax support, action params and setpropertylisteners all fail to set "key" information into a backing bean which would give the precise information needed to find out what's been selected, whether that information is the table's rowkeyvar or var.

So you have to use a Selection and find out the row index. This is useless if your table is sortable as there is no way to get access to the sorted row indices to then work out which domain object you need to play with on the server, despite that information being contained within the table! Sorting wouldn't be an issue if could transmit my "key" as mentioned above.

Furthermore your demo, to which I was pointed, at http://livedemo.exadel.com/richfaces-demo/richfaces/scrollableDataTable.jsf?c=scrollableDataTable&tab=usage demonstrates that sorting the rows breaks the popup "row selected" functionality. And this is a demo you lot are proud enough of to make publically accessible?

Sad to say that I've been badly burned by rich face and have no faith in the abilities of the developers and managers working on it. I could accept excuses if it were something esoteric I was trying to do, but something this fundamentally broken is laughable. The fact that none of the team can provide any answers to this, not even admitting there's something inherently wrong is strange.

I'm now going to roll my own sortable (and row-selectable) table using myfaces. I did it in the past, I'll do it again. And I'll now think very hard about using rich faces in the future.

[maguri]

I think this is not the way to express yourself about others people work and effort. It only shows the kind of miserable prig creature you are. And yes, Richfaces has bugs and problems. I suppose your brilliant self-made components are awsome and just perfect (That is really laughable). Go on, don't waste any more time of your precious, magnificent life. Do it all yourself. It would be perfect for everyone.

[peterjca]

You've missed the point. Of course my software has bugs (from subtle ones to stupid ones), but all the major use cases and functionality has test cases so I can catch most failures most of the time (assuming my code is appropriately covered).

I had a quick look at Ice Faces. This toolkit has the concept of a rowselectionlistener on a table (i.e. there is a rowselectionlistener tag and Java object for it). So, by design that functionality is present on the table and (hopefully) has tests written against it. RichFaces, on the other hand, does not have the concept of row selection on a table. You can supposedly get there by jumping through suggested hoops, none of which works. Had RichFaces designed row selection on the table, tests would have caught it not working and you wouldn't be in the embarassing situation of having a broken demo (which, according to the forum was drawn to RichFaces' attention over a year ago and is still not fixed).

Consider the "noDataLabel" attribute that was added to the extended table. Great idea. Erm, where is it on the scrollable table? Ooops, not there because the tables do not share the same immediate ancestory. Doh! It reinforces my belief that RichFaces has evolved through hackery rather than by design.

(BTW, I solved the row selection + sorting with the scrollable table by doing the old trick of walking the component hierarchy and fiddling with row keys. I also solved the absence of a nodatalabel on the scrollable table by wrapping the table in a custom component (NoDataAwareTable), adding it as a child, and having the nodatalabel in a facet of the custom component, with a renderer conditionally rendering based on the row count.)

Sorry, but I can't understand why RichFaces 3.3 has such a major usability problem that hasn't been caught by unit or integration testing. It's not version 0.95 after all.