Adding a Filter Subfield plugin and associated changes

[akshaisarma]

Hello @mistic100. Thank you for this awesome QueryBuilder plugin. I work at Yahoo and I want to get your thoughts on the following.

We use a fork of the QueryBuilder internally for a couple of our tools. The fork is mainly because we had to add support to show a subfield for filters (i.e. filters are not just a select dropdown and depending on the value of a particular item, an extra text input is shown whose value the user enters and qualifies the filter). We have tried to abstract it into the plugin model and while we were successful, the numerous touch points that this change creates, renders the existing events system insufficient in accommodating all of them.

While we were able to use the events system for a lot of them, for others we had to do some hacky stuff to get around this (Disclaimer: the developers who worked on this are also not Javascript experts and learnt it recently). This includes wrapping original function calls in QueryBuilder by saving a reference to them, overriding them, doing our custom stuff and calling the original methods inside the overridden methods. This is in order to not touch the original QueryBuilder code. It is also inefficient (iterating over the model more than once) because of that. Some of these methods are:

getRules, setRules, addRule, updateRulefilter, updateRuleOperator

An example of what I mean by "wrap" the original code:

    setRules : function(data) {
        this.modify(data);
        originalSetRules.call(this, data);
        this.modifyModel(this.model.root);
    }

There are also other minor changes in the fork such as modifying the sql plugin to accommodate the new subfield (by adding new events to the sql plugin)

The reason I am reaching out to you is because we want to open source the tool that uses the modified QueryBuilder plugin in its UI. This means that we'd need this modified QueryBuilder also open sourced. Do you think there is a need for the subfield plugin in QueryBuilder? If so, to do it properly, we'll need at least more events that lets the plugin developer have more control over what goes in and out of the methods listed above. Are you interested in having this in QueryBuilder? If not, would you amenable to adding more events so we can implement it as a plugin without resorting to hacky changes?

Thanks in advance!

[mistic100]

Hello

There were already requests for filters selection split in two select boxes (they are in this issue tracker but can't find them), I closed them all because I don't have time to implement it.
I always recommended to use optgroups, which is not a very good solution when there are numerous filters.

But if you came with a clean, optional and easy to configure solution I will be more than happy to merge it.

Requirements :

• respect the overall architecture
• do not include breaking changes
• keep it simple for the developer AND the end user (the target of this plugin is people who don't know what is a boolean or and SQL clause)

[akshaisarma]

Let me describe a bit more about why we need a text field and not a second select box. The filters are essentially column names in a data source. There are some columns that are composite types like maps or structs. The keys inside these composite types are unknown up front. The user specifies them in the subfield. Together with the map/struct name and the subfield, the full filter is made.

This makes sense for how we use it but does it make sense to have in the original QueryBuilder? If so and you are ok with entertaining a PR for this, is it ok in our changes to introduce new events into the QueryBuilder events system?

[mistic100]

As you describe it : no, it's too complex for QueryBuilder.

But you can request and/or PR new events, new methods or anything technical that might also be useful for other people.

[akshaisarma]

Great, I'll discuss this internally and get back to you in another issue for events modification if needed.

Is there an easy way you can recommend a plugin to be open sourced without including the source of QueryBuilder? If I understand correctly, the only way to get a plugin into the dist version of QueryBuilder is to have grunt task concatenate all the src files together. Is the solution another custom grunt task that pulls in querybuilder and concatenates the new plugin code with the distribution of QueryBuilder? It seems like all new plugin developers would have to deal with this issue, unless they contribute to this repo.

[mistic100]

Incorrect.

It's documented here http://querybuilder.js.org/dev/plugins.html

And there already are separated plugins http://querybuilder.js.org/plugins.html#other-export

[akshaisarma]

Thanks for your help!