I did da lot of research during the last weeks on how to implement a report for the following scenario:
After three weeks I have the following research results:
foreachconstruct in Advanced XML
What I have come up with after three weeks is the following approach to implement the complex report:
foreachconstruct to iterate over search results, I do the search in advance and then use a regex replace pattern to generate the outer enclosing view XML, that runs the sub-reports on the particular search result items
includeconstruct for including a view as sub-view into the current view, I use the
IFrameIncludemodule for including the sub-view into the main view
<module name="IFrameInclude"> layoutPanel="messaging"><param name="src">/app/xxx/dev_single_subject_report?loggerId=myFoundLoggerId01</param></module>-- It seems that the XML display of code fragments gest somewhat mangled, if in doubt, look at the source code of this post to see what I meant
URLLoadermodule of the SideviewUtils app to make the HTTP GET Parameters available to the sub-view context
PostProcessmodule to filter the saved search result for the particular subject passed to the sub-view
This approach has the following disadvantages:
pdfhandler.pyto specify the option
JSChartmodule sporadically fails to render the result of a post-processed saved search, which sporadiacally results into the SideviewUtils
HTMLmodule displaying the search result and the
JSChartradial gauge next to it (rendering the same search result) failing to even show the result. Not very useful ina fully-automated scenario. This has been confirmed by Splunk to be a bug in JSChart 
I hope some splunk experts in the community have some Ideas on how to improve this approach or show a completely different approach
Interesting question. Is the requirement to have a single view or simply a single PDF? If it's the latter, you might consider a custom search command to iterate over the results of the generating search and create each view separately. Then you could merge the resulting PDFs, either with a command line tool or in Python itself (I found some code samples with a quick search), and email it through the script, or maybe generate an alert with a link to the file location. I've never tried anything like this, so I don't know how feasible it is, but maybe it's helpful.
1) Multiplexer module.
A long time ago I created a prototype module called "Multiplexer" for use cases like yours.
Although it's still very much marked as a prototype module, it does actually ship in Sideview Utils 2.0.X, and I'd be interested in your details and requirements to see if it really can be a good solution for you.
How you use Multiplexer, is you give it a param called 'field', and you make sure that it only has one downstream module, or child. Note that although it has only a single child, that one child can have as many other children and descendants as you like.
How it works, is that it will inspect the values of the given field, across the current search result. And for every value in every row that it sees, it will clone that single sub-branch of modules. If the field param is "myField", then $myField$ can be used within the downstream param values, and for any given multiplexed child, it will refer to that row's value for the myField field. It's a little brainbending but it makes sense quickly.
The good news: It works great with HTML modules and a number of other simple modules. Also, it can be paged, meaning you can put a Multiplexer downstream from a Pager module, and then it will only 'multiplex' 10 at a time. And clicking page 2 will then 'multiplex' the 11th through 20th values.
Since you're using Sideview Utils already, I recommend simply putting an
<iframe> tag in an HTML module. IFrameInclude does some strange things which don't add much, and in fact often get in the way. However note that the HTML module will re-render it's HTML with every context push, so you'll be happiest with this approach if there's only one push and the overarching view is not very interactive.
3) The JSChart bug. Unless I'm mistaken it was me that initially reported this bug to Splunk, and I think i've already patched it if you're using the latest 2.0.X version of Sideview Utils . I will however double check that and update this answer.
4) dynamically creating views.
It's been done. Yes it's sad and unfortunate that there's no way of including a shared fragment of view xml. However some cool things have been done dynamically generating XML, adding, editing, deleting xml files, and then hitting the refresh endpoint.
5) print delay.
It's an interesting use case, but I think I can probably wire URLLoader into the PageStatus system, so that when URLLoader sees that hte parent page is another Splunk view on the same domain, it can register itself as another player in the game, and you would then be able to take that extra sleep out. I'll add an item to my queue to investigate and possibly implement in a future version of Utils.
Could work, but I assume this to be alot of effort until it works seamlessly (I did not write a custom search command yet, so I am not sure how much work that would be).
My intention was to use 'all-stock' splunk functionality for my reporting, as I want to have power-user being able to copy the template and build their own reports on top of this. Thus shell-scripting and stuff sound a bit complex for me.