I want to build a form where one can enter a single value (say, a user ID) and this value is then used in multiple searches (for examle a list of logins, a list of transactions made by this user, a list of pages accesses by this user etc) which each produce a table/list of results, and I want the results to be available on one dashboard. I have looked into the documentation for advanced views, forms and dashboards but was not able to construct such a view (hiddenfield and postprocess search do not work, as I have some compeltely differen searches, but which all use the one value as dynamic parameter).
The docs are good, but when it comes to the UI they don't have the depth and the examples of the UI Examples app. You should pay very careful attention to the first three "intro" pages it lists under 'Advanced XML'. Even if you think you're familiar with advanced XML, there will probably be things written there that are new to you.
After that the example you're probably most interested in is under "Advanced XML > Lister examples > One lister driving multiple elements".
And as for learning about how to use the HiddenPostProcess module, pay close attention to the "Using postprocess on dashboards" page, also in the UI Examples app.
The trickiest thing to understand, and the thing that's not explained very clearly anywhere, is 'when and where in the XML do all the searches get kicked off'. Judging from what you're saying I suspect you've had a bunch of confusion around this yourself. I've been meaning to add a docs page to Sideview Utils to cover this, but maybe I'll start here. 😃
Data essentially flows down through the Advanced XML toward the leaf nodes. As it passes each module it might pick up another argument or some other modification to the search like an intention. And when it hits a fork it multiplies and now there are N snowballs, one to each branch in the fork. Now some modules "require a search to be running". Like EventsViewer, or FlashChart, or JobProgressIndicator. In practice it's easy to figure out what these modules are; just ask yourself if the module can do its job when there's no running search for it to talk to. If it cant, then it will "trigger a dispatch". eg:: ResultsHeader cannot display the number of results if there's no search, so therefore ResultsHeader triggers a dispatch.
So you've got the core concepts now. Now here's how searches get kicked off: When a snowball of data hits a level of the XML tree where there is at least one module that triggers a dispatch, the search will get kicked off then and there. After the HTTP traffic is done and the search is running, the snowball continues running downstream towards the leafnods except now the data now contains the appropriate references to the running search whereas before it was just a bunch of arguments really. If someone changes something in the search data, like if there's a second TimeRangePicker down there, or if there's a whole other 'HiddenSearch' module, that first job gets kicked out of the snowball and a second set of arguments accumulate, until it hits a second tier where at least one module requires a dispatch.
It's not the easiest thing to explain, but I hope it's clear now.
Let's take a later point in the story for some closure -- a minute later say, when the user hits the submit button a second time. This just means another snowball starts down and the same thing happens. As soon as it touches the first level where there's at least one "dispatching" module, a new search gets kicked off (and if there's an old one around that was dispatched at that point it gets cancelled).
So if you read down through the XML of your view, and you think about each level in turn, "does this module need a search, how about this one", you can usually find the spot where the searches get kicked off without much trouble and this really does become helpful in understanding why things might not be working out the way you want. In particular it's quite common for people to use PostProcess but use it in such a way that multiple searches end up getting kicked off anyway.
And if/when you need to know for sure whether a given module is 'Dispatching', look at the autogenerated module docs at `http://:/en-US/modules In the entry for each module you'll see whether it extends 'DispatchingModule' or 'AbstractModule'. In a couple cases it'll be something like 'AbstractPagedModule' but just go and look that up to follow the chain.