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. Two suggestions: 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. ... View more

1) It's a little weird to use $click.*$ tokens if you're using Sideview Utils, because the Sideview tokens are a lot more intuitive and flexible. If the first column in your table is "user", then I would replace $click.value2$ with $click.fields.user$. It will work the same; it's just easier to understand. 2) At first I thought with $testfield$, that you weren't intending that to incorporate anything from the drilldown row, but perhaps you are? If so, if there's a column called "testfield" in the results, then you want $click.fields.testfield$. If I had to guess, I'd say the "it works for only one row" mystery is somehow related to there being a form element module upstream whose name is actually "testfield". ... View more

This is what the ValueSetter module's "allowClobber" param is for. That param defaults to true, meaning that the ValueSetter module will set the key(s) even if there are existing values from upstream. However you can set the param explicitly to False, in which case it will have the behavior you're looking for. Namely, the ValueSetter module will provide the default if there's none in the URL, and it will defer to the URL value when there is one present. The page for the ValueSetter in the Sideview Utils docs speaks about all this. Go to that page in the app's navbar "Module Documentation > The ValueSetter modules > the ValueSetter module", and check out the paragraph titled in bold "Setting fallback defaults with "allowClobber". As always, if you're on an older version of Sideview Utils make sure to upgrade. The latest version is 3.3.1 and available for free from the Sideview website at http://sideviewapps.com/apps/sideview-utils/ ... View more

This was indeed a bug and has been fixed in the latest release (3.3.1) available on sideviewapps.com And I am sorry for the lag replying - I could have sworn I had added a comment acknowledging this was a bug but it appears I didn't. ... View more

I recommend taking a step back and looking at Table Embedding to solve this problem. Here is a simple config that adds two columns to a Table. In each column is a link, and by clicking the links the user can either search a particular field value in Google, or in Bing. <module name="Search" autoRun="True" layoutPanel="panel_row1_col1"> <param name="search"><![CDATA[ index=_internal source=*metrics.log group="per_sourcetype_thruput" | rename series as sourcetype | table sourcetype | fillnull google bing value="value not used" ]]></param> <module name="Pager"> <module name="Table"> <module name="HTML" group="row.fields.google"> <param name="html"><![CDATA[ <a href="http://google.com?q=$row.fields.sourcetype$">Google it</a> ]]></param> </module> <module name="HTML" group="row.fields.bing"> <param name="html"><![CDATA[ <a href="http://www.bing.com/search?q=$row.fields.sourcetype$">Bing it</a> ]]></param> </module> </module> </module> </module> But looking at this, you'll probably wonder "why are there two columns at all. If we can render arbitrary html and links, why don't we just put both the link tags into the same table cell? So here's a version that does exactly that: <module name="Search" autoRun="True" layoutPanel="panel_row1_col1"> <param name="search"><![CDATA[ index=_internal source=*metrics.log group="per_sourcetype_thruput" | rename series as sourcetype | table sourcetype | fillnull search value="value not used" ]]></param> <module name="Pager"> <module name="Table"> <module name="HTML" group="row.fields.search"> <param name="html"><![CDATA[ <a href="http://google.com?q=$row.fields.sourcetype$">Google it</a> <a href="http://www.bing.com/search?q=$row.fields.sourcetype$">Bing it</a> ]]></param> </module> </module> </module> </module> Table Embedding is extremely powerful and flexible, and like almost all the features in Sideview Utils, it has it's own docs page with working examples, inside the Sideview Utils app itself. remember to always get the real Sideview Utils from the Sideview website rather than the very old version on apps.splunk.com. Another way that people sometimes try is to hack together a solution with the legacy SimpleResultsTable module but I do not recommend this. For the record though, you could use SimpleResultsTable module's weird ability to highlight/select both rows and columns, (setting its drilldown param to "all"), and then they try and fish out the column that the user clicked using the $click.name2$ token. The problem usually is that there are only a couple columns where the given behavior is desired (in this case clickability), and the problem becomes how to turn off the behavior for the others. You could in theory do this though, use the old SimpleResultsTable module and then have some drilldown modules like ValueSetter try and sort this out with the ValueSetter's conditional logic. and then pass to a Redirector. However I do not recommend this. ... View more

OK. There are two problems here. 1) HiddenChartFormatter is not a Sideview module, and it does not do $foo$ substitution. So with this param <param name="charting.chartType">$chartType$</param> unfortunately it is trying to set the chart type to the literal string "$chartType$" including the dollar signs and all. Solution: Either a) you can use the Sideview module ValueSetter with the one line param <param name="arg.charting.chartType">$chartType$</param> ValueSetter is a Sideview module so it does do $foo$ substitution. or b) You can simply change the "name" param of your Pulldown to already be "charting.chart", using: <param name="name">charting.chart</param> and then you don't need either ValueSetter or HiddenChartFormatter. Instead the key will come right off the Pulldown already with the right $foo$ name. 2) This brings me to the second problem. Right now you have the Pulldown configured with: <module name="Pulldown"> <param name="name">$chartType$</param> but you can't wrap that in dollar signs or it wont work. Instead you would want this: <module name="Pulldown"> <param name="name">chartType</param> Here are some other improvements you can look into, although these are kind of extra credit things to help simplify and make things more readable. 3) Assuming you're on 2.X or 3.X, you can replace this: <param name="searchFieldsToDisplay"> <list> <param name="label">MESSAGE_TEXT</param> <param name="value">MESSAGE_TEXT</param> </list> </param> with just <param name="valueField">MESSAGE_TEXT</param> Or, since the name of the Pulldown module is MESSAGE_TEXT, you can replace it with <param name="valueField">$name$</param> which can further reduce copy-paste mistakes 4) I'm confused by what the $$starttime$$ and $$endtime$$ tokens are doing in there but that looks very wrong. Do you have querystring arguments whose names themselves have dollar signs in them? You don't want that if so and it's probably causing some problems. 5) It's extremely awkward to have <param name="separator">\"+OR+MESSAGE_TEXT=\"</param> <param name="outerTemplate">( MESSAGE_TEXT=\"$MESSAGE_TEXT$\" )</param> What you want instead is just <param name="template">MESSAGE_TEXT="$value$"</param> <param name="separator">+OR+</param> <param name="outerValue">( $value$ )</param> Or, since the "name" param is "MESSAGE_TEXT", you can use the $name$ shorthand again: <param name="template">$name$="$value$"</param> <param name="separator">+OR+</param> <param name="outerValue">( $value$ )</param> 6) You may want to use the CheckboxPulldown module instead of using a Pulldown in multiple-selection mode. The behavior is a little different, in that all of the options are selected by default and there's no "all" option, but quite often that actually matches what people want. 7) You should have a Message module in the view. Most Sideview modules, when they have some critical error to communicate to the user or to the developer, will do so in a big red error message within their own space. However some older modules and error conditions in the framework itself still rely on the old Message module to display errors. So therefore if you don't have a Message module there, you may be hiding very useful error messaging from yourself. ... View more

Well generally if two Sideview form element modules are aligning next to eachother left-to-right, it's because the one on the left has an explicit param on it that is doing so: <param name="float">left</param> In which case removing the param would give you the default behavior where they are each on their own line. Often working module config is pasted around from view to view so this might have been in there all along. Failing that, the other thing I can think of, is maybe your modules are in the layoutPanel called "splSearchControls-inline", which is a bit of an outlier among the layoutPanels. That layoutPanel actually builds a little invisible table with a single row, and puts each module in the panel into its own cell in that one row. Then it always makes the first cell as wide as possible and it smooshes the rest together. It's designed to do SearchBar + TimeRangePicker + SubmitButton, and it works great for that combination. However for pretty much any other situation it's not a very useful layoutPanel and I advise avoiding it in your views. A third possibility, is that someone has put some float rules into application.css, or into a custom css file that they've added. The best way to rule that out is to use something like Firebug on Firefox, or the page inspect tool in Chrome, to look at the live CSS affecting your modules. Those tools will break out exactly what CSS rules are applying to your elements, and what files they are coming from. So if you see a "float:left;" on the leftmost of your two modules, figure out what file is doing it and why it's there. ... View more