Looking for a way to improve my dev-sessions.
I have a fairly complex dashboard/view requirement at the moment, requiring up to 10+ levels of nested pulldown controls, and another 10+ levels of custom textbox controls - before actually getting to my searches/charts/tables
The problem I am experiencing at the moment is - even with a wide enough computer screen, the text-editor (sublime in this case) will wrap some of the nested modules/params so much I can hardly read the content. Also turning off text-wrap is not really an option since many of the search/postprocess strings can get fairly long.
I am looking for a way to split up a single source-file (advanced xml) into multiple-files, such that I can include/embed those inner/nested modules into a hosting/master dashboard/view
Anybody tried this before?
Most likely switch to DJango and the Web Framework, if thats the case; but at the moment, I'm just working on a prototype - so will have to stick with advanced XML... for now...
There is no way in Splunk's advanced XML or the Sideview XML to reuse or import part of the XML from an external file. This may very well come in a future release of Sideview Utils; a big step towards that end goal has at least been taken somewhat recently.
1) Are you using the Sideview Editor? If not and if you're editing the XML files by hand, one simple trick is to manually "reset" the indentation at some sensible point, like after the last shared pulldown/textfield module. Then you get the benefits of indentation and word wrap but you might avoid the terrible problem you're having with your view.
2) If you are using the Editor, there's a weird trick you might try. The Sideview Gate module can be used to teleport a downstream push from one point in the XML hierarchy to another. It's a very advanced module and this is outside of it's normal use cases, but you could
a) put a Gate module just downstream from your last shared Pulldown/TextField module
<module name="Gate"> <param name="to">viewBody</param> </module>
and no other modules there.
b) Then you could have another top-level module in the view:
<module name="Gate"> <param name="id">viewBody</param> .. all your Search modules, HTML modules, Table modules, JSChart modules etc, would go here. </module>
and then nest all the Search modules and display modules inside that Gate module, rather than downstream from the form element modules.
Again the Gate module is very advanced, and it's not really intended for this. A more normal use case would be wiring up three different drilldowns on three different charts to all push inline drilldown results to a single shared table/chart. However it should work here. Just be careful to only put autoRun="True" on the top of the form-element module chain, and have no autoRun attribute on the dangling Gate module.
Thanks for the tip. Will definitely become more intimate with the "Gate" module in coming days. Just a quick note though, the Gate module must be placed inside the level of a "URLLoader" module - meaning the Gate (id) module cannot be place at the same level as the URLLoader; otherwise the view won't be able to load.
just a quick note to those uninitiated, I am using the gate module to solve my problem now. primarily due to the fact that I have upwards of 20 text boxes in a dashboard, and each must be pre-populated by a lookup value, so essentially, for each textbox I place, I will be forced to use the following modules (hence the source-file indentation becomes pretty insane): Search, ResultsValueSetter, ValueSetter, TextField
Technically all the URLLoader keys should come through the Gate, but you might be right, there might be a grey area here which can be worked around by moving the other Gate below URLLoader. Out of curiosity did you actually try it with the Gate at the top and saw that it didnt work?
Also, if you can send me your full XML I can quickly scan through it and there may very well be some tricks or simplifications I can find for you to do the same thing with less xml. nick [at] sideviewapps.com
Actually, I first tried putting the URLLoader inside the Gate - since I figured I would just use the Gate as the outer most module; but then realized it wouldn't work, so I took apart the xml file, removing the irrelevant, and using only the most basic structure for testing. And it turns out that the URLLoader must be the outer most module. In fact, although the view loads properly if I put the first Gate (id) at the same level as the URLLoader, it turns out the upstream-context doesn't get passed down. Therefore as a final solution, I use URLLoader as the outer most module, and all Gates (id) are children to this URLLoader module