Disabling filter clauses in FilterBuilder

[danaconway]

SmartClient_v120p_2020-01-08_PowerEdition

I have a client that would like to build some filters for a ListGrid using the FilterBuilder, but have the option of toggling filter clauses in order to specify whether or not they should be included in the grid filtering. In essence, they want to be able to disable/enable each filter clause instead of having to remove and then re-add some common filters that they use.

I thought that I could accomplish this by using isc.defineClass to create a subclass of FilterBuilder. I have two scenarios that I'm considering.

One thought was to add a disable button and the attributes/functions I need to make that work. However, after searching around a bit, I could not find an example of how that could be done (adding a disable button to the FilterBuilder component). Are there examples or documentation somewhere that I could reference in order to accomplish this? I see that the addButton, removeButton, and subClauseButton are AutoChildren. So, would this even be possible to do?

Another thought was to override the removeClause function to capture what that clause is when they remove it and put it in a list in memory for them to easily retrieve and re-add. Although, this could get quite complicated with the AdvancedFilter and they would then have to specify where in the nested clause to add it back in.

The FilterBuilder is quite nice and I would hate to have to implement a custom solution to handle this situation.

Any thoughts, suggestions, or guidance on accomplishing this would be greatly appreciated.

[Isomorphic]

Those AutoChildren are accessible as doc’d and you could call disable() on them, and add your button to the internal layout of the FilterClause, but that’s a somewhat dubious approach in terms of forward compatibility.

Another approach would be a VStack of FilterBuilders, where you add the disable button externally to each FilterBuilder and use it to disable the FilterBuilder as a whole.

You then manually combine the criteria from all the FilterBuilders that aren’t disabled, which is easier than stripping parts of the criteria out, necessary in the first approach.

This second approach has the drawback that clauses could only be disabled at the top level - individual parts of nested clauses could not be disabled because the disable buttons only exist at top level. But it is simpler and clearly maintainable.

Finally, you could use the Feature Sponsorship program to have this added as a core feature, or to have APIs added to make your own implementation easier and more maintainable.

[danaconway]

Thank you for the reply. I understand what you are saying, and agree with the drawbacks to each approach.

What is the Feature Sponsorship program? I am not familiar with that.

[Isomorphic]

It’s a program where you can have a feature added to the framework if you just pay development costs.

https://www.smartclient.com/services/#features