Nested form/list validation errors are not being cleared

[ermouth]

Nested form/list validation errors are not being cleared

[ermouth]

In short, for list of of forms .check prop is strictly boolean, it governs whether errors in subforms are reflected to this.my.errors() and this.my.valid(). So if .check in list declaration is boolean and subform(s) has errors, calling this.my.errors() returns smth like {'#list':{15:{'#someCtrl':'Some error'}}} where 15 is zero-based index of the subform with error.

If you want to check overall list health (some meta-conditions, like no identical elts, or odd number of entries required etc) you better follow common practice for this sort of tasks:

• you make a proxy div somewhere, it may be hidden or reflect some useful info about list state, ie elt counter or sort of stats
• that proxy div has own ui section and .watch:['#listToFollow'] inside, so it checks on list changed
• div’s bind function contains all logic to check list health and, optionally, to output a message
• also that proxy might have say .delay:500 not to be called too often or if the tracked list requires some time to stabilize.

So it’s not a bug, it’s about bad documentation and, well, a design mistake happened long ago, I admit. I was pretty sure it’s reflected in docs, but seems it’s not. I’ll fix documentation, but design is widely used so I can’t change it without breaking a lot of things, sorry.

[ermouth]

Updated docs:

• http://jquerymy.com/api.html#CW-validation
• https://cloudwall.me/api/jquerymy#h-18pgz8sy

[alexmurari]

@ermouth it doesn't make any sense that the errors don't disappear after the child form is valid again.
Why are the errors added when the check function is invoked but don't get erased when the child form is valid again? If they are added when the check function returns a string (the error message), it's possible that they get erased too when the function doesn't reeturn anything.

Resorting to hacks like ghost divs to achieve a somewhat simple functionality like ensuring form validation defeats the purpose of this library that is to simplify code. And it does a great job at it, I've managed to create a form with repeated child forms, each with select2 controls that one depend on another in a clear way. No more boilerplate code to copy values from controls to objects and vice-versa. This library is really great.

[alexmurari]

Well... looks like it was indeed a bug. Tested here and now the errors are being cleared.

[ermouth]

it doesn't make any sense

The background of this behavior is pretty reasonable. By its nature the this.my.errors() object is a tree which branches are named after control selectors. So inevitably if a control is a list, its error cannot be a string, only an object which is a collection of subform error objects. You just can’t put any list error message into object, which makes functional validators merely useless. We can reflect (or not) underlying errors automatically.

Also if a list could apply .my-error css class to itself on error, it would mark – visually – all inner controls as also having errors, which is awful in terms of ui.

So it is as it is.

Resorting to hacks like ghost divs

The ‘hack’ of proxy objects combining states of other controls is a long standing very standard practice employed by different platforms and frameworks, starting with old IBM mainframes. I didn’t invented it.

It doesn’t need to be a ghost, it may be Save button which disables on errors, however ghost proxies are also very useful.

Tested here and now the errors are being cleared

In a way you did it it will not be accepted, it breaks a lot of things, and you put it in wrong part of code, sorry. I’ll think how to make it properly.

As I understands specs are:

• if we have a check function for lists, it receives list data array, and returns a string;
• the sheer presence of .check function for a list means we do not even try to collect errors from subforms and always rely on that function;
• this function knows nothing about errors in subforms.

This might be reasonable. Here is one missing part: how to deal with .my-error class, should it be applied on a list container? Any thoughts?

[alexmurari]

how to deal with .my-error class, should it be applied on a list container?

It shouldn't be applied at all when the check function is at the "list" level and not "single control" level, you just don't have enough information about which control is invalid, and there's no way to guess it, apply it to the list container level would be really terrible because it would turn everything red. 😆

On this line, you was expecting that list form objects entered the if block, thats why I added the isList condition to the if.

[alexmurari]

Maybe something like this would give the necessary information:

// list level
check: function (d, v){
    const emptyNameIndex = v.findIndex(t => t.name == "");
    if (emptyNameIndex  !== -1)
        return { control: "#name-input", index: emptyNameIndex,  message: "Name cannot be empty." }
}

Then, you would have the offending control selector. Maybe the index property gives some clue about which element of the form list will get the .my-error class. Considering that the data array order and the form list order are the same. Form lists are really tricky.

And, yeah, smells like breaking changes... maybe.

[ermouth]

Error message should be a string, or a dict of selector:error|dict pairs, otherwise we get inconsistent structure of errors object.

As I see it, subforms and lists containers may just receive another error class name, not .my-error, but, say, .my-error-list or smth. It might allow automatic error tips show/hide with css only, and all that stuff.

If a function wants for some reason return an object, it might be an artificially recreated object of standard error structure, with additional ""(empty string) key for meta-error message (I mean a message for entire block, which goes into error-tip obj automatically). Or, if no errors, we just return empty string or {} or {'':''}.

[ermouth]

Btw this way of validation has one huge issue: it’s O(n^2), each subform change induces validation of all rows in a list. So proxy isn’t so bad idea after all.