And here I thought sarcasm was just my thing.
I get what you're saying - but my point is their seems to be a need for a hierarchy - between the list and menu params (not just here, but in numerous places, like for some plugin params) - and this only complicates that. And IMO the menu params should always take precedence.
"a overrides b" is simple enough. (both for the end-user to understand and for coding)
But now you have "a overrides b unless c is..."
I also agree that the list configuration is the logical place where the common/global list pre-filters should be. But if I was in your shoes I would have just added a radiobutton option in the menu/module params for the pre-filters with the options to either 'Add to' or 'Overwrite' the list pre-filters. Otherwise, it creates a situation in your code where you have to go back and forth between the 3 possible scenarios trying to figure out which one to use.
What if there are some instances where you would want the list prefilters to be "Overriden by menu/modules" - and some places where you don't? My question is whether the list parameters is where that option should be set - i.e. having it in the 'parent' list parameters prevents it from being implemented on an individual basis in each menu item, no? Or am I missing something here?
It seems like you (or much of the Fabrik code pertaining to list parameters) assume that each list will only have one front-end menu associated with it. But this particular list I am working with is being used in 8 different menu items - each with it's own unique prefilter and selected elements settings.
It's one of those chicken and egg things, but there needs to be consistency throughout the fabrik code - and IMO the final arbitrator should always be the menu/module parameter settings. What I am proposing is to move the CSV parameters into the menu/module parameters - because that is where it is most likely that there is going to be a need for unique prefilters, elements selected, and ALL of those CSV options that only show in the List parameters yet cannot be changed in the menu parameters. So why bother having it all in the List parameters? - unless you want to always use that only as a default if nothing is set in the menu/module parameters (which makes sense too, I suppose - and would eliminate any worries about 'backward compatibility')
As I mentioned - I have a similar issue with the 'Overwrite' option of the CSV Import settings. In some lists (menu pages), I don't want the user to be able to select that option, I want it to always be Yes - and yet (if the Frontend option isn't displayed, so the user can't change it) the default for the Overwrite will be 'No'.
So what I'd like to see for all of those Yes/No radio button settings in the 'csv_auto' section in the list.xml file is a 3rd option - 'User'. If 'User' is selected then the user gets to make the Yes/No selection in that mootools csv option popup on the front end - otherwise whichever of the other Yes/No options that was selected in the params would be used. Similarly, that is how my dilemma with the 'Overwrite' option for the CSV Import could be handled/solved too. ( I already have the code written to show/hide each of those options in the list.js file csv popup, as appropriate, using this method.)
This CSV import/export code is the biggest offender when it comes to having the ability to configure params based on the 'menu' list - vs. the 'list' list. But I have come to realize that there is a lot of code for 'import' and 'export' that shares functions - and a lot of the difficulty in attaining a more desirable and user-friendly functionality probably has a lot to do with some hysterical (my word for historical) code. And I understand how that happens over time, but it still doesn't mean I'd not like to be able to help to fix that.