Refreshing ResultSet Renderers
Jeff
all ResultSetRenderers in a given Report. This would be attached to a
'Refresh' button to be added to the Report Editor. I'm looking to get
some insight from those who are more familiar with code in QueryCache
and it's related classes.
My first attempt was to iterate through the Report's content boxes,
and for each ResultSetRenderer, execute it's query, and see if the
ResultSetRenderer is already setup to update itself, but it doesn't
appear to be. I noticed ResultSetRenderer has a 'queryChangedListener'
with the comment:
/**
* This listener will fire a change event when the query changes to
signal that
* the result set renderer needs to be repainted.
*/
But from looking at the code I'm not sure when, if ever, it receives
any events.
It also has the comment:
//XXX This is not a property change. It should either be a new event
type
//or handle it directly.
which suggests to me that it is intended to be replaced at some point.
Any suggestions on how to go about implementing this 'refresh'?
-Jeff
Jonathan Fuerth
> It also has the comment:
>
> //XXX This is not a property change. It should either be a new event
> type
> //or handle it directly.
>
> which suggests to me that it is intended to be replaced at some point.
I'm not super-familiar with that code, but I think we should take a
clue from the way OlapQuery works: it promises to deliver the CellSet
to all registered OlapQueryListeners whenever the query has been
executed successfully.
>
> Any suggestions on how to go about implementing this 'refresh'?
I think you're on the right track. I kind of wonder if there's any way
to bend the CellSetListener in such a way that it can also serve as a
ResultSetListener, but this is probably just a bad idea. On the other
hand, how would we deal with a picture changing, or a chart, or a ....
Perhaps we need some sort of "new data available" event that just
tells you the source WabitObject that has the new data and provides
the data as an Object. Then we could subclass it for each type of new
data (ResultSet, CellSet, Image, ...) and use the fun "covariant
return types" feature of Java 5 to narrow the type of both the source
WabitObject and the new data item itself. This would mean we'd need
some instanceof checks in some (but not all) of the event handlers.
It doesn't strike me as ideal, but I think it's a lot better than what
we have now. I'm open to suggestions!
-Jonathan