I’m having multiple pulldowns and one TextField. If I change the values of the TextField alone, it’s not getting pushed downstream. If I change one or more pulldowns along with TextField, then, both pulldown’s and TextField values are pushed downstream.
Is this known issue? Anyone having any work around ?
The TextField is only pushed downstream when one of the Pulldowns above it is changed. So if we want to include the TextField value in our search, we have to enter the text and after the text has been entered, change one of the Pulldowns. We have tried using both the Splunk Submit button and Sideview Button.
Working on posting anonymized code...same code can be found in this post though: http://splunk-base.splunk.com/answers/66080/sideview-pulldown-having-downstream-effect
It's a confusing problem. Fortunately it has a very simple fix, and unfortunately it has an incredibly confusing explanation.
Simple Fix: reorder your view XML so that the Search module is downstream from the Button module. Currently you have the reverse.
In greater detail, currently your Search, TimeRangePicker and Button module are in this order:
Search TimeRangePicker Button
adjust them so that instead you have:
TimeRangePicker Button Search
the functionality will be exactly the same in all ways, except that this bug will go away.
First, if you have a relatively current copy of Sideview Utils (2.2 or above), go to the app and navigate to "Key Techniques > Overview of the Advanced XML". That page was recently rewritten to have a much improved explanation of how the view XML works, and that broader explanation there will help understand the following specific one.
OK. 1) The Splunk UI forces modules to be configured in an explicit hierarchy. 2) Data (think selections from form-elements) passes down through that hierarchy, but the data only passes down when there is a "push". 3) pushes will always redispatch all searches that are necessary to feed the modules present downstream.
(see framework docs in Sideview Utils for a longer discussion of essentially these same three points).
These three things force a brutal simplification into what would become quite complex UI problems and this ends up mitigating a lot of the event-driven chaos and cruft that ends up tangling up other modular UI frameworks, at least in my experience.
In the case of Pulldown, a "push" is initiated every time the module is changed. In the case of Button, it's initiated when the green button is clicked. Across the board modules that "push", have an unambiguous "time to push" and "time to not push". Except for a very couple outliers-- the most notable outlier is TextField.
In the case of TextField, a push is initiated when you hit enter while focused into the text field. OK. However if you just type some characters but you don't hit return.... well. What's a framework to do. If we push with every key press then every downstream search will redispatch. (see #3). So pushing with every keypress is out. On the other hand if we let the UI state change but we don't notify downstream modules we're creating a problem...
So let's call this a weird grey area for now and come back to it later. It's a situation where we need to push but we can't. This problem is somewhat unique to TextField. Again, Checkbox, Table, JSChart, Pulldown, Tabs, etc... these all have unambiguous cases for pushing and unambiguous cases for not-pushing, and no grey area like TextField has.
So let's walk through the concrete case where we change the value in the TextField by typing into it, and then instead of hitting return or changing a Pulldown to trigger a push, we use the mouse to click the Button module. Well because the TextField never did a push, the Button module will only have an older copy of the data, back from the last time a push came down through.... Hence your bug. The Button initiates a new push, it pushes the search that the Search module gave it a while ago, but that push is bad because that Search incorporates a stale copy of the TextField's value.
Now, behind the scenes, the TextField module is very much aware of this problem, and in fact it makes a very determined effort to walk through the downstream module hierarchy and carefully erase the cached $foo$ keys down there and replace them with updated ones. It actually does this on every keypress. (yes writing and testing this code was a lot of work and a little scary). In TextField's internal terminology it calls this a "pseudoPush". There is however a remaining set of cases where, even though TextField rewrites its own key, it has no way of rewriting secondary keys, ie keys into which the TextField value has been incorporated as a part of a larger whole. I didn't realize it until today, but actually $search$ is one of those cases. To be precise, the TextField goes and rewrites all the OPTVALUE keys downstream, but it doesn't realize that the Search module has already incorporated that into the $search$ key, so the search key remains out of date.
again.... short version: When you have a Button module, the clicking of which dispatches a search as defined by a Search module, put the Search module immediately downstream from the Button. Bug goes away.
As a reward for having read this far, you can read the comments on the TextField's pseudopush method. Depending on your version of Sideview Utils, it will say either "Sorry Nate you were right", or it'll have a somewhat longer and more professional explanation including "Nate was right. There's a catch-22 here." These comments are in reference to a bit of a debate Nate and I had as to the seriousness of this very problem, way way back probably in 2008. maybe 2009.