The ResultSetStreamer will need to have access to parameters, its own configuration and to the actions of the user (selected columns, etc.)

I have included the period merge use case as attachment.

Implemented in SVN rev 756.

Some docs see http://cocoondev.org/xreporter/docs/core/reports.html#dsy86-cd_row_handlers

I have made a sample implementation of the period merger, and a sample report using the data provided in the use case. See the report 'residency.xml' in the the testconf.

Bruno, I took a quick tour through the implementation and it looks at first sight what we need. Bravo! The PeriodMerger itself isn't finished since there should be 0..* sum columns, but the most important issue is that the mechanism of ResultSetStreamers (or row-handlers as it has been named) is implemented.

Just a remark however. I think a row-handler should have access to ALL columns selected from the database and not just the columns the user selected. Of course, this implies a row-handler having access to information on whether a column is selected by the user. I have a use case at hand where this would be a nice (necessary) improvement. Just think of a kind of head count on all people of department where the individual employees aren't in the output. The employees can have 1..* contracts in 1..* departments. Here I would want the row-handler to have access to the id's of those employees.

Thanks for the quick feed back.

I committed some changes in SVN rev 771, the list of all ColumnDefinition's is now available via the OutputContext, the data of all these columns can be retrieved via the RowValues object.

The PeriodMerger will need another patch to ignore the non-visual columns.

Unless I'm overlooking something, I think it is ok like it is.

However, there is probably some confusion from the difference between:

- the Column[] array, which is the array of visible columns
- the ColumnDefinition[] array, which is the array of all columns

Since you don't really need the Column objects (all we ever do is Column.getColumnDefinition()), I have now simplified things: both for selected and all columns, the array of ColumnDefinition objects is provided, and the methods to retrieve them on OutputContext have better names now.

In case there's nonetheless an error, please correct me.

OK, you were right. But it was a little confusing as you agreed with...

One hopefully final remark on this matter... As I had noted before a row-handler works best under the condition of a certain ordering of the initial ResultSet. I would want to be able to check that ordering and implement then a failover when the user messed up the ordering. So I would like to have access to that user modified ordering. I am not sure whether this requires new instruments out of the xreporter box. What is your opinion on this? Maybe a small example can clarify how to handle this...