No reloading. Automatic.
If you look at my original idea of refreshing the child parameter then you can look at it as a work around for dynamic parameters.
But with Jonathan's insight he did a better job than me but ended up using the filter shelf. This then caused a terminology issue. So the whole thing is quite nice and complicated, but to do with how we describe things.
Tableau is a weird tool :-)
I'm not sure how long you have used Tableau, but it looks like you are trying skip some steps and become a Zen master before you have studied basic principles of this software
This is how I learn :-)
My background is SSRS (reporting services) and there the concept of dynamic params is straightforward. Each parameter has its own data source and you can assign a dependency from one param to another giving rise to nesting. But tableau for some reason hard codes everything. Big pity.
That's why pointed that it's good to learn basic principles of the software before you try to implement same methods that you have used with other programs
I encourage you to investigate new possibilities, but sometimes it's good to check what others have tried. That way it's easier to find out, is your solution something that will solve existing problems.
True but I have actually gone through the online documentation and videos. I have worked on it for about 6 months so for.
But I find the way it works is strange. Non standard.
I think because its basically a pivot table on steroids and designed not for developers but non technical users.
So weird concepts come out.
This is how it looks to me. :-)
I'm not too familiar with SSRS, but I've always thought having a .pde (Parameter Data Extract) would be a better solution to how Parameters are used now.
My idea (Though not fully worked out) would allow for Parameters to become their own datasource that lives outside of the primary datasource in the workbook (Extract, Live Connection, etc). But still has connections to our source data (db, excel, etc). By having a connection to the source data, we could do both simple refreshes based on Dims or Row Level Calculated Fields (Not including FIX LoDs).
This would allow for scheduled refreshes, dynamic updates, and, since it would be a datasource (Not hard coded XML), multi-select functions. Also, since it would be an Extract, could be loaded into other workbooks.
We would be able then to interact with it similar to blends, but minus the necessity of aggregated the Secondary Source (In this case the .pde file). So Table would first Query the .pde file for Values selected in the workbook/viz and then add them appropriately to the Calcs being fired off from Tableau either to the Extract, or the Live Connection.
There are a lot more details I have left off, but this is the general gist. Plus....we could have a multi-valued parameters with DATES, and thus better resolve the issue with having a Datasource with only Start and End Dates.
Yes this would be a big step forward. But from what I understand about the tableau strategy, I think they are not going in that direction. They focus on non techy users rather than us techies. This is the impression I got when a Zen master gave us a talk the other day, and also described the features of v9 etc
From a user perspective, this wouldn't be much different than how Parameters are used now. You would still have a Pane for Parameters, Parameters would still look/feel like Filters (Single Dropdown, Multiple Dropdown, etc), and you would still write calculated fields to interact with them.
The only substantial difference (From a user perspective) would be the added ability to create a .pde file, load a .pde file, or refresh a .pde file. The latter two could be very similar to how you load and refresh a Workbook or Datasource.
I don't work for Tableau, so I can't speak directly on their strategy, but I think it's not so much about techy vs non techy, as it is about usability. But there is a limit, in order to get to next level analysis, you have to have some "complex" things like LoDs (Which can confuse even "techy" users). So really it's a balance.
All that being said, there is still confusion between what "dynamic parameters" actually means. I didn't really understand this until recently, after I started this conversation We don't need "Dynamic" Parameters.
Quickly, I learned that my "ideas/opinions" on the matter didn't fit everyone's situation. And that, yes, though there are some uses cases that are better solved without parameters, there are still many reasons why we need them. So in order to get "next" level, we have to first define Parameters (In all respects), and then have features (architecture) that allows for freedom to explore.
Sorry, this is a lot of me just thinking as I write!
Shawn Wallwork wrote:
Ali if you would change the title of this entire thread to "Using Parameters To Control Content of Quick Filters", then probably nobody would have said a thing. This is something most of us understand how to do.
Agree 100%. Is there any way to get the topic title changed so we don't confuse anyone in the future into thinking that this has anything to do with dynamic parameters please ?
Happy to change this if the admin want me to. So for you guys dynamic params just means it refreshes automatically rather than manually correct?
Ali yes, a 'dynamic parameter' has to at least be something that changes the parameter itself without any manual intervention. Otherwise the request would be for Manual Parameters (which of course we already have).
And yes I think it would be best to rename this thread to something a bit more appropriate, because folks will search for Dynamic Parameters, find this thread and either be confused, or get frustrated after reading the whole thing and finding out that the promise of a good solution for dynamic parameters is not actually delivered.
What should I call it though? Because for me it is a dynamic implementation of sorts. And in SSRS this is a kind of dynamic (or nested) parameter. Because the child changes according to the parent.
How about: Working with Nested Parameters