Example of multi-field validation?

[bryanspears]

A use case: I have two, numeric text inputs. One cannot be greater than the other. How would I validate that using ampersand input/form/whatever and still have input errors/messages work without extra code?

If you do it at the input level using test methods (which only have local value available), you have to use external variables (self.model or something). If you do it at the form level it's the same issue where data available internally to the object isn't enough. If you do it at the model level (with validate()) then you have the issue if manually triggering an invalid state on inputs.

I really hope someone has a simple answer for this. I haven't found one yet.

[cdaringe]

hey @bryanspears. indeed, at the form-level, there's not a place to do so. the form maintains validity strictly as a subset of it's child field views' validities. because of this, similar to how @fyockm's password-view works, the real only clean way to do this ATM is to make another Field View to manage the relationship. you could perhaps do some hacks to listen to key events and set some state on the form by sniffing the form's _fieldViews, but then you break the contract of trusting the form's .valid property, which may eventually lead to more head banging! arg! making a FieldView isn't too much work. https://ampersandjs.com/learn/forms#form-input-view-conventions

[bryanspears]

Hey @cdaringe. I appreciate the quick response! So the idea would be to group two input views in another view to validate the updates?

Also, I'd be interested to see the password-view you mentioned, if you have a link. I couldn't find it via that user or google search.

[cdaringe]

@bryanspears, exactly. it definitely feels like a bit of overhead for a seemingly simple case, but it's the pattern. here's his password-view: https://gist.github.com/fyockm/81830ae9574d72fe34e2 . I've done some as well, but unfortunately they are still closed source (working on that!)

[bryanspears]

I started doing something very similar to the password-view after your original comment. However, doesn't this mean I have to re-implement much of what &-input-view already does for me? Error class, messaging, etc.

If I had some large, custom interaction between 2 or more fields, this would make sense, but all I need is to add a test to one field that compares its value to another field's value. :disappointed:

[cdaringe]

i hear ya man! i was in the same boat when i got started. one of my first cases was building a field that sourced data from either an < input > or a < select > based on another piece of state. i somewhat hacked around it and it ended up being a real pain. i really regret not doing it per the book.

it may not be a bad idea to extend FormView to add optional tests form-level. in that regard, you can test each at the field level, and at the form level. it could be a pretty dang easy extension, I'd think. @wraithgar may have opinions on that. @bryanspears, take a peek at the FormView source--it's compact. you may consider prototyping it

[wraithgar]

I seem to remember there was some sort of bug we fixed that allowed form inputs to validate based on the states of other inputs in the same form, as I had some inputs that were only active/valid if other ones were filled out or omitted.

ETA: Looks like it was this one: https://github.com/AmpersandJS/ampersand-input-view/pull/49

So perhaps you need to visually decide which input is the "lead" and let it do the validation?

[cdaringe]

well there's a simple solution!

[bryanspears]

So I've played around with the three different ways of doing this I've discovered so far. They all feel horribly clunky. We already have one example of validation based on all fields (in the model validate() method) why not extend similar behavior to form/input? Yes, it could place more logic in single inputs than I'd prefer, but considering the messaging, the error state, and more is held within the &-input itself, and not in the &-form or view, then it feels like the only concise location to put said validation tests.

tests: [
    function (val, fields) {
        return (val < fields.otherFieldName.value) ? "Cannot be greater than otherFieldName" : false;
    }
]

[cdaringe]

@bryanspears, i think adding tests at the FormView level is a valid request. I am def open to a PR if you'd be interested in giving it a whirl

[bryanspears]

My suggestion was intended for input-view (I know, wrong repo, but we have a great discussion going).

If at the form level, there's no way to manually trigger the error state on an input-view. The only way to do so is the tests on the input itself.

[bryanspears]

On second thought, maybe that should be the real fix. &-form already has the validCallback and all we'd need to change on input-view is enable externally triggered error states/messaging. Then a user could implement multi-field or model-based validation errors/messaging at the form level when necessary.