All Apps and Add-ons

HTML module tabs module and switcher module

subtrakt
Contributor

Hi!
I'm new to foo tokens and probably could use a little hand-holding!

I have a dashboard with a auto-refresh check-box at the top and would like it to be unchecked automatically when Tab "test2" is selected which would ultimately disable the dashboard auto-refresh! Is this possible with $token$?

<module name="HTML" 
...
name="autoRefreshCheckboxes"
checked="$foo$"&gt;
...  
</module>

($foo$ = True|False)

<module name="Tabs" layoutPanel="panel_row1_col1" autoRun="True">
<param name="name">selectedTab</param>
<param name="name">foo</param>
<param name="staticTabs">

<list>
<param name="label">test1</param>
<param name="value">test1</param>
</list>
<list>
<param name="label">test2</param>
<param name="value">test2</param>
</list>
</param>
<list>
<param name="value">True</param>
</list>
<list>
<param name="value">False</param>
</list>

<module name="Switcher" group=" ">
    <param name="selectedGroup">$selectedTab$</param>
    <param name="selectedGroup">$foo$</param>


<module name="NullModule" group="test1">
<module name="NullModule" group="True">
    ...test1 tab content
</module>
</module>

<module name="NullModule" group="test2">
<module name="NullModule" group="False">
    ...test2 tab content
</module>
</module>
1 Solution

sideview
SplunkTrust
SplunkTrust

Presumably you're using a Sideview Checkbox module together with the Sideview AutoRefresh module and using the AutoRefresh module's normal mode of "pushDownstream". In this default mode the AutoRefresh module just initiates a push every N seconds. (and from there it's the framework and the downstream modules that work out whether or not any searches have to be dispatched.)

If the second tab contains searches that you don't want autorefreshed, I think the way forward is simpler than trying to uncheck/check the autorefresh checkbox up above (which solution by the way would lead you into some second-order interaction problems).

But at a high level it seems that what you want is a state where the checkbox and autorefresh effectively become useless or irrelevant whenever the second tab is open, and relevant when the first tab is open.

1) EASY: move both the Checkbox and the AutoRefresh inside the first tab. You are done. yay. The autorefreshing and the checkbox are only relevant inside the first tab. the user is not confused and you have no extra moving parts to remember later.

2) A BIT WEIRD: If we left the checkbox and the autoRefresh at the top and if we just put a Button module at or near the top of the content inside the second tab, and set both allowAutoSubmit and allowSoftSubmit to False on that Button, then the push from the upstream AutoRefresh will die there. Only the user clicking the second tab's green Button can make the second tab's searches dispatch.

Granted, the user might be a little confused, since when the second tab is open the checkbox appears to say autorefresh is on, yet the second tab never autorefreshes...

3) HARDER: do the same as #2 above but also throw a ShowHide module into the content of each Tabs. These ShowHide modules could make the autorefreshing Checkbox control only appear when the first tab is open...

ShowHide is a nice and simple invisible module. When a push hits it, it can show zero or more CSS selectors, and optionally hide zero or more other CSS selectors. So in tab 1 you would have:

<module name="ShowHide">
  <param name="show">.Checkbox</param>
</module>

and in tab 2 you would have

<module name="ShowHide">
  <param name="hide">.Checkbox</param>
</module>

And you might use the cssClass param on the Checkbox to give yourself a more fine grained CSS selector than ".Checkbox".

But I suspect the answer is more like #1 - rearranging the page flow and thus the UI to suit your interaction requirements more closely.

View solution in original post

sideview
SplunkTrust
SplunkTrust

Presumably you're using a Sideview Checkbox module together with the Sideview AutoRefresh module and using the AutoRefresh module's normal mode of "pushDownstream". In this default mode the AutoRefresh module just initiates a push every N seconds. (and from there it's the framework and the downstream modules that work out whether or not any searches have to be dispatched.)

If the second tab contains searches that you don't want autorefreshed, I think the way forward is simpler than trying to uncheck/check the autorefresh checkbox up above (which solution by the way would lead you into some second-order interaction problems).

But at a high level it seems that what you want is a state where the checkbox and autorefresh effectively become useless or irrelevant whenever the second tab is open, and relevant when the first tab is open.

1) EASY: move both the Checkbox and the AutoRefresh inside the first tab. You are done. yay. The autorefreshing and the checkbox are only relevant inside the first tab. the user is not confused and you have no extra moving parts to remember later.

2) A BIT WEIRD: If we left the checkbox and the autoRefresh at the top and if we just put a Button module at or near the top of the content inside the second tab, and set both allowAutoSubmit and allowSoftSubmit to False on that Button, then the push from the upstream AutoRefresh will die there. Only the user clicking the second tab's green Button can make the second tab's searches dispatch.

Granted, the user might be a little confused, since when the second tab is open the checkbox appears to say autorefresh is on, yet the second tab never autorefreshes...

3) HARDER: do the same as #2 above but also throw a ShowHide module into the content of each Tabs. These ShowHide modules could make the autorefreshing Checkbox control only appear when the first tab is open...

ShowHide is a nice and simple invisible module. When a push hits it, it can show zero or more CSS selectors, and optionally hide zero or more other CSS selectors. So in tab 1 you would have:

<module name="ShowHide">
  <param name="show">.Checkbox</param>
</module>

and in tab 2 you would have

<module name="ShowHide">
  <param name="hide">.Checkbox</param>
</module>

And you might use the cssClass param on the Checkbox to give yourself a more fine grained CSS selector than ".Checkbox".

But I suspect the answer is more like #1 - rearranging the page flow and thus the UI to suit your interaction requirements more closely.

View solution in original post

Did you miss .conf21 Virtual?

Good news! The event's keynotes and many of its breakout sessions are now available online, and still totally FREE!