I have a dashboard that uses the Search Module ---> Table Module ---> Gate Module. The Gate module transports tokens to another Gate Module that sits idle waiting for the 'row.fields.ext_refid' value in order to launch it's downstream modules.
What I want to do is automatically have the drilldown occur on the first result in the table module. This way users won't have to click the first row to drilldown.
I tried:
-use "ResultsValueSetter" to create the token "ext_refid" before the Table Module
-then, in the table module, I use the default param as follows:
default.row.fields.ext_refid = $ext_refid$
Using the SideView Utils Editor in RunTime Debugger Mode, it looks like the value is being interpreted literally as $ext_refid$ instead of the token value.
Is this possible? I have a feeling it is and I'm overlooking some simple procedure.
Nope. you're not overlooking anything. It's just a bug. The logic for the Table module's default.* params didn't anticipate that you would do $foo$ replacement on the values. Very often you guys just think of these crazy use cases before I do.
I'll get it fixed in the next maintenance release - which should come before Christmas if not sooner.
In the bigger picture, (and separate from that quite valid bug you found), this solution is a bit ugly - you're using ResultsValueSetter to duplicate the values of the first row and then plugging those values into the default.* params. Maybe it would be better to be able to tell the table to treat row N as initially selected when the page loads?
Nope. you're not overlooking anything. It's just a bug. The logic for the Table module's default.* params didn't anticipate that you would do $foo$ replacement on the values. Very often you guys just think of these crazy use cases before I do.
I'll get it fixed in the next maintenance release - which should come before Christmas if not sooner.
In the bigger picture, (and separate from that quite valid bug you found), this solution is a bit ugly - you're using ResultsValueSetter to duplicate the values of the first row and then plugging those values into the default.* params. Maybe it would be better to be able to tell the table to treat row N as initially selected when the page loads?
hehe. Believe it or not I've written customBehaviors to do exactly that. With some help from postprocess to figure out what "page" the given result row is actually on, and then some tinkering with Pager to go to that page. Sideview's app for Cisco CallManager has a page where a couple tables get selected to dynamic values and the Pager/Table automatically loads that page. 😃
Although I wasn't thinking of going that far into Wonderland, it's actually not a terrible idea... I'll look into providing such a feature.
"Maybe it would be better to be able to tell the table to treat row N as initially selected when the page loads?"
Absolutely. For me it would be the first row in all cases (at this time).
If I go down the rabbit hole a bit further...I can imagine a case where I might want to auto-drilldown on a result with a specific key=value pair as apposed to "row 'n' is initially selected". But now you need to incorporate the Pager Module huh? What if the row with the 'match' is on page 10? These are rhetorical questions btw.
Anyway, thanks. Your answer is perfect for what I'm looking for.