rule dependencies

The old library had the ability to make rules dependent on others, i.e. re-evaluate a binding when other bindings are updated; now, this won’t work:

<input type="password" value.bind="password & validate">
<input type="password" value.bind="passwordConfirm & validate">

Assume passwordConfirm must be equal to password (supported for example in aurelia-validatejs with @equality) the passwordConfirm & validate binding should trigger also when password changes, but the binding behavior doesn’t know about the implementation specifics so it won’t update/render when password is changed.

[pettys]

I realize this is a pretty old thread, but still open, and I’m hit by this currently.

@dkent600, to offer an answer to your question, “is it sufficient…” I think your proposed solution (a custom rule applied to all involved properties) would not work well for the password form of the original question, in terms of the error renderer. Here are steps I’m thinking of:

1. Enter password = “abc”
2. Enter confirmPassword = “abc”
3. Go back and enter password = “def” Expect behavior: “passwords must match” error rendered on the confirmPassword field. Actual behavior: “passwords must match” error rendered on the password field. (Comment: this might be a bit odd, but maybe acceptable.)
4. Enter confirmPassword = “def” Expect behavior: errors all cleared. Actual behavior: there is nothing triggered to revalidate the password field; the error doesn’t go away. (Comment: this behavior seems not ok.)

In summary: although your solution would help get errors on the screen in any case, in a dependent property scenario, errors potentially need to clear when another property changes.

As another example, closer to what I’m dealing with today, a user must enter two numbers, a required positive number, and then another number which must be greater than the first. The domain suggests that this “greater than” rule belongs on the second number, but hard to get it to work right.

My main point is I think a property dependency mechanism of some sort is still warranted.

[dkent600]

It seems to me that any “rule that depends on another rule” should be defined as a single rule using .satisfies(), no? I’m not clear what is the use case where this would not be appropriate or possible.

But using satisfies still presents an issue.

My use case:

I am validating at the object level, thus must manually call ValidationController.validate().

Each object contains object rules (defined by ensureObject().satisfies()). These object rules do not depend on other rules, but they do relate to a set of properties on the object. However, unlike with ensure().satisfies() it is not possible to associate ensureObject().satisfies() with a property name, much less with multiple property names.

Further, I am using neither the validate binding nor a ValidationRenderer. Again, I am manually calling ValidationController.validate(), and manually rendering the error information when validate completes.

A ValidationRenderer could be useful for me in this scenario, but it is not, for the following reasons:

1. without using the validate binding, it does not provide the element(s) with which a property is associated.
2. it provides neither property names nor elements for rules define by ensureObject().satisfies()

Thus I propose the following:

Add a parameter propertyNames to ensureObject().satisfies(instance), like this: ensureObject().satisfies(instance, propertyNames?: string[])

Change the type of ValidationError.propertyName from string to string | Array<string> (or have it always be an array). Perhaps change the name of ValidationError.propertyName to the plural ValidationError.propertyNames

I think this fits fairly nicely into the existing paradigm.

This will help with #351