Your idea of having a master list, and then forcing requeries on the children lists by comparing them to the Names in the master list is pretty innovative, but I think it will be problematic.   Skuid does not automatically re-set the values in “Field from another model” conditions when you requery those models. You have to reset the values of the conditions,  which will be difficult in this case. 

We have been able to use what we call “Arbitrary filters”   where a field editor control updates data in a “filter model”.   When those fields are updated - values are passed to conditions in one or more models and these models are requeried. 

Here is a link some XML where this is shown for one model.  But using the action framework you can extend this to multiple models. 

https://github.com/skuidify/SamplePages/blob/master/ActionRecipies/Arbitrary_Filter.xml

Another page that Zach had built might be helpful.  Again it only filters one model right now - but because it is using the action framework,  there is no reason it can’t filter multple models and thereby control multiple charts and tables. 

https://github.com/skuidify/SamplePages/blob/master/ActionRecipies/FieldEditorFilters.xml

Enjoy. 

Thanks Rob! I will look into these posts. Meanwhile, I read somewhere on community that if I update all the models (child and master where filter is present) in single call like below; it resets the conditions too.
skuid.model.updateData([aModel, bModel, cModel]);

I checked & it actually works. However, if I call this code from action framework and on ‘requery of master model’ event; all the charts and tables with child models keeps on refreshing as the code execution goes into infinite mode. So, my question is there any other event where I can call this script when the filter is changed? I mean- I need to know filter change event and the corresponding arguments.

DJT; 

I’m not going to reccomend that you pursue the direction you are suggesting.  While it might be feasible,  it will require some custom code, and be more complicated than an alternative declarative solution. 

Here is that simpler solution (as propotyped in the xml files above)

1. Rather than using table filters to control the master,  use field editors on a single record in a “master model”.  The field editors probably should be in edit mode and can be placed anywhere on the page.  

2. Create actions on that model that listen to changes in the fields in your field editor. 

3. When changes are detected,  update conditions in your children models with the value selected in the field editor.  Then requery the children models. 

Zach’s page is a good model for this. 

Hopefully this doesn’t require too much reconstruction on your part.  But its the better way. 

Rob,
Thank you for your support. I incorporated Zach’s idea in my page and it looks good. It works on multiple models. However, the filters on field editor- which are just fields - are not as powerful as actual Skuid table filters. For example, I cannot have multiselect option filter for picklist field. I might try custom snippet for this though.
But for now, this solution looks good. I will provide more updates on this to J. Tingle with whom we have weekly meetings scheduled.
Thanks again!