I like idea with Column interface with encodeAll method and cell encoder object with startCell/endCell methods. To be sure I should try to prototype this approach (in separate branch or sandbox).

Seems it's time to decide, should our iteration components work with standard jsf column component or no? I think they shouldn't. Supporting only richfaces component reduce/clear code and bring in more flexibility for the iteration renderers e.g. we could move all cell rendering logic into the column renderer and remove it from the table. (BTW I am not sure that this is a right way seems this won't work with ExtendedDataTable cells because of cell markup deference in comparison with 'simple' dataTable cell markup.)

SubTable:

"expand/collape" feature brought in much complexity in the iteration renderers code. I suggest drop this feature from the subTable component or implement it in the separate components e.g. SwitchableSubTable.

"expand/collape" feature brought in much complexity in the iteration renderers code. I suggest drop this feature from the subTable component or implement it in the separate components e.g. SwitchableSubTable.

even confirming all the problems and for sure being agreed with base classes redesign idea - I'm very sad about the proposals to remove something which will be already announced to customers even if it will be returned back later(when? ). It looks not good at all for me. I'm interested if we have any other alternative.