This concerns an Advanced XML dashboard with the SimpleResultsTable.
I have a SimpleResultsTable (parent) with a dataOverlayMode parameter set. This contains a drilldown which eventually leads to another SimpleResultsTable (child). It does not seem to matter what I do in the child params, I cannot remove or change the dataOverlayMode. The same thing happens for the drilldown param.
Is this a bug or am I missing something?
Example snippet of XML
<module name="PostProcess"> <param name="search"> ** my main search **</param> <module name="SimpleResultsTable"> <param name="dataOverlayMode">heatmap</param> <param name="drilldown">row</param> <module name="PostProcess" layoutPanel="panel_row3_col1"> <param name="search"> ** my drilldown search **</param> <module name="SimpleResultsTable"> <param name="dataOverlayMode">none</param> <param name="drilldown">none</param> </module> </module> <!-- PostProcess --> </module> <!-- SimpleResultsTable --> </module> <!-- Postprocess search -->
Thanks for any help!
It's a bug.
1) The SimpleResultsTable listens for the dataOverlayMode key from upstream, so it can respond to external controls turning the mode on and off.
2) If a SimpleResultsTable ever has dataOverlayMode in its params, and it also receives one from upstream, the upstream one wins.
3) Unfortunately the bug is that SimpleResultsTable also provides the contents of that param, as a dataOverlayMode key to downstream modules. =/
So the first table is telling the second table what to do, and to ignore its own config. I believe the same bug exists with displayRowNumbers.
You're already using Sideview Utils, so assuming you're also upgraded to a recent version then you can use the Table module instead of the SimpleResultsTable. While it doesn't have a feature that exactly duplicates the dataOverlayMode, it has two features called Table Embedding and Table Rendering that together cover a far greater range of heat-map and custom-rendering type functionality.... depending on your use case it might get a bit finicky but if so spell out that use case in another question and I'll try and help.
Thanks for confirming it is a bug. Any sign of it being fixed?
For my current situation, your suggestion is perfect, and in fact I only need to make my child module a table (and can leave the parent as SimpleResultsTable) - I really should have thought of that!
I will now go and play with table embedding and rendering to see what can be done for any future issues.