This is what happens when you make custom modifications. You may get left behind.
Can you tell what you need to achieve? Maybe there is already standard approach for it.
We have different datatables in our project, and we have written a class that downloads the contents of the datatables to an Excel file (using jxl jars). But some columns don't need to be downloaded, whereas for some columns (which contain elements like rich:comboBox/rich:select), we need to show Yes/No, True/False, etc. values. We wrote Java code to iterate over the datatable, as follows:
For this, in the code, we iterate over each row of the datatable (which is a subclass of UIData in RF3.3), using data.setRowIndex(i). Then, we iterate over the columns from that row using data.getChildren().iterator(), and write the contents to an Excel file.
The problem that is happening after migrating to RF4.1 is that the richfaces datatable is no longer a subclass of UIData - it has a getRowIndex() method but not a setRowIndex() method. So unable to set the row to extract the column values from.
I think that creating Excel file based on datatable is not task for a component but for business method, thus you should work with datamodel instead.
Also adding yes/no radios or checkboxes is usually done by binding such controls to Map attribute of backing bean.
You probably need generic backing bean (maybe abstract class) rather than modifying the component.
From my point of view abandoning a jsf standard base class; which many other frameworks use as an integration point was an odd decision. I really don't think dgenharsh's use of the UIDataTable is so much the point of the question. Almost all thrid party component libraries (PrimeFaces, Tomahawk, etc) have components which operate upon any component that extends the UIDataTable base class. I assume that the rich faces team had a good reason for departing from using this more standard base class. Sadly the effect of this decision is isolation from many other custom or third party components which us the standard table base class as it's point of integration.
This may be something to reconsider in my opinion. In my perspective extending all data iteration components from a non standard base class makes using the richfaces table implementations much less adaptable than it would be otherwise.
Now from my point of view the original question was asking for guidance on iterating the rows of a rich datatable or any of its children. From glancing at the javadocs it seems that one of the base classes of the richfaces UIDataTable is UIDataAdaptor. This class has an iterate and walk method which may be able implement the functionality asked about in the original post. Sadly the documentation on these methods is a little vaque and I would need to do more reading and possibly some testing to determine if these would fit the bill.