Overall querybuilder validation

[jnedley75]

Is it possible to obtain a true or false value (or something similar) that signifies the entire querybuilders validity in terms of all the fields that are present in the current query being built?

I want to be able to include the query builder in a form validation to be able to disable/enable a submit button whenever the querybuilder has invalid or all valid field entries.

[ukrbublik]

Currently, there is no such requirement (or flag that enables such requirement) to have all fields "enrolled" in the query value.
If I understand you correctly , you have fields a, b, c in config and want to check that query value is like a == 1 && b == 2 && c == 3 but not a == 1 && b == 2

[jnedley75]

Not quite, so for instance say we have a single AND clause that has two fields in the builder. Given those two fields are entered in valid, is it possible to obtain a flag / value that signifies that all of the fields are entered in valid.

[ukrbublik]

Can you please provide examples of good and bad query values?

[jnedley75]

A good query value would simply be all fields included in query pass the validateValue method. A bad one would be if 1 or more of those fields do not pass the validateValue method.

In a nutshell, the value I'm looking for is something that flags if any of the values entered into the fields are currently invalid per the validateValue method

[ukrbublik]

Utils.isValidTree
Does this method work for you?

[jnedley75]

This actually does work, although I may be experiencing a bug where I have validate value return (val.length >= 1 && val.length <= 30).

It shows invalid when the initial tree is loaded on page load but whenever a character is entered and deleted (type a character then backspace back to length 0) the field still shows as valid. It doesn't do this however for the upper bound, only for the lower bound

[ukrbublik]

Probably it's a bug with validation of empty values (empty value can bypass validation).
Please submit an issue for this

[jnedley75]

Issue is submitted as a bug in #781