Independent and dependent dropdowns in advanced XML

[cphair]

Hi all,

I have an advanced XML dashboard that has several dropdowns. They are labeled Parameter 1, Value 1, Parameter 2, and Value 2, but there may be more parameter-value pairs in the future. The Parameter 1 and Parameter 2 dropdowns provide a list of possible fields--they're populated by the same saved search, but otherwise they should be completely independent of each other and everything else on the form. Value 1 and Value 2 contain the possible values of the fields from Parameter 1 and Parameter 2, so naturally they depend on the value selected from those dropdowns. My problem is that I can't seem to code the XML in a way that makes Parameter 2 independent of Value 1--every time I change Value 1, it regenerates the search for Parameter 2. Also, I can't use the Parameter 2 dropdown until Value 1 is selected. I've tried setting applyOuterIntentionsToInternalSearch to False for the Parameter dropdowns and True for the Value dropdowns (since they take the selected parameter as an intention), but that doesn't seem to help. I looked through the UI examples but didn't see one that fit my case. Can anyone suggest how to let the Parameter dropdowns run their searches independently, and the Value dropdowns to only depend on the single Parameter dropdown they belong to?

I also would like the dropdowns to be laid out in a logical way, stacked in two columns in a single panel:

Parameter 1         Value 1

Parameter 2         Value 2

(etc)

...but I can't seem to get the parameters to layoutPanel correct.

[sideview]

Dealing with the issues separately -

1) Second set of UI elements is being refreshed when the first set upstream is changed:

There are several overlapping issues here. First, since you're using the core SearchSelectLister module, that module can only populate itself dynamically using the search it has defined in its own params, plus some number of intentions. In particular it cannot leverage an existing search from upstream, in conjunction with a dynamic postProcess search. Secondly, that module will always reload its options using that internal search whenever it receives a push from above.

The intentions stuff isn't really the issue here, surprisingly, at least there's no way to craft an intention that could tell the SearchSelectLister to not bother reloading its options.

The only workaround I can think of using just the core UI, is to make the second set of SearchSelectListers use scheduled saved searches. Then when they redispatch, at least in theory, they should reuse the same previously-run job that they ran with the first time. However I haven't used that stuff in a while so I could be wrong, and even if I'm right, to get the values for the given parameter2, you cant use previously scheduled results -- instead you'd have to use the savedsearch search command or maybe loadjob and that would get a little messy.

If you had Sideview Utils of course, these problems go away and you have more than one way even to get what you need. First, the Pulldown module doesn't have its own special internal search; rather it gets its results from the main search results. The major upshot of that is that you can render 2 or more Pulldowns quite easily using only one dispatched search, but with a postProcess param on each. In theory you could have one search contain all unique combinations of parameter1 and value1, appended to all unique combinations of parameter2 and value2 - and then all Pulldowns would reload pretty much instantly even when they did decide to reload.

Furthermore, as of Sideview Utils 2.2.7, the Pulldown module has been made a lot smarter as far as knowing when to reload its options, and when not to. In the new behavior, when Pulldown receives a "push" from above, but

a) The search id of that push is the same as it was last time options were rendered**
b) the postProcess search is the same as it was last time options were rendered.

Then the Pulldown does not actually refresh it's options at all. In this case there is of course no real need since the new options would always be identical to the old ones.

This means you can have quite complicated hybrid cases where some Pulldowns are partly dependent on some other Pulldowns, but the UI will never "jitter" more than absolutely necessary.

** as to how to rework the view such that the push does not redispatch the search, the only trick is to place a "dispatching module" at or above the level where the push is going to be originating. Often this simply means factoring up a JobProgressIndicator, or if there is no other option, putting one of these at the right spot:

<module name="CustomBehavior">
  <param name="requiresDispatch">True</param>
</module>

If you are fuzzy on when, where and why the Splunk UI dispatches searches in custom views, you should read the "Key Techniques > Advanced XML Intro" page in the most recent Sideview Utils because it has a comprehensive explanation that will make all this relatively clear, or at least a bit less baffling.

** modules arent lining up in the layoutPanels the way that I'd like**

the most reliably way, whether you're using Sideview Utils or not, is to apply some custom CSS and use float:left; and clear:left to lay out the form.

If you have modules A, B and C, and you want B to be alongside and to the right of A, and you want C to be on its own line no matter what, you would apply a float:left style to A and to be safe you should apply a clear:both style to C.

Past that I often monkey with the widths of the label elements inside the Pulldowns, and the min-width's of the select elements and this can make the overall layout line up very nicely.