v2.9.4

Release v2.9.4.

v3.0.0-beta.5

• #294 [BUGFIX] Validate promise resolves even when validations are still validating

v3.0.0-beta.4

• #266 Check for null in extractOptionsDependentKeys @xcambar
• #272 Fix ember-cli deprecation warning

v3.0.0-beta.3

• #262 Use model instead of _model when declaring custom dependents (backwards compatible)

v3.0.0-beta.1

• #241 Fix blueprint warning
• #245 Utilize root in validator blueprint
• #249 Fixed email regex of format validator @simonihmig

Some more CPs for your CPs

Upgrade Notes

Computed Options

In 2.x, we introduced the notion of Options as Functions which allowed any validator's option to be a function that would
be lazily called right before a validation happened. In 3.x, we noticed that such implementation very much resembled the
workings of a Computed Property (without the caching of course). Converting our functional approach to an Ember CP approach made defining validations a whole lot simpler.

Before (2.x)

validator('length', {
  dependentKeys: ['isEnabled', 'meta.username.minLength', 'meta.username.maxLength'],
  disabled(model) {
    return !model.get('isEnabled');
  },
  min(model) {
    return model.get('meta.username.minLength')
  },
  max(model) {
    return model.get('meta.username.maxLength')
  },
  description(model, attribute) {
    return model.generateDescription(attribute);
  }
});

After (3.x)

validator('length', {
  disabled: Ember.computed.not('model.meta.username.isEnabled'),
  min: Ember.computed.readOnly('model.meta.username.minLength'),
  max: Ember.computed.readOnly('model.meta.username.maxLength'),
  description: Ember.computed(function() {
    // CPs have access to the `model` and `attribute`
    return this.get('model').generateDescription(this.get('attribute'));
  }).volatile() // Disable caching and force recompute on every get call
});

Some more reasons why this is better:

• Any option that uses a CP doesn't have to re-declare those dependents in the dependentKeys collection.
• You can use any Ember.computed operation (computed.and, computed.or, computed.filterBy, etc.)

dependentKeys

There might be instances where your validator is dependent on external properties. For this reason, we introduced dependentKeys in 2.x. In 3.x, the only change to this is that all dependent keys must be prefixed with model.

Before (2.x)

validator('presence', {
  presence: true,
  dependentKeys: ['someService.someProperty', 'foo', 'bar.baz']
});

After (3.x)

validator('presence', {
  presence: true,
  dependentKeys: ['model.someService.someProperty', 'model.foo', 'model.bar.baz']
});

New Features

Warning Validators

Any validator can be declared as a warning validator by setting isWarning to true. These validators will act as assertions that when return a message, will be placed under warnings and warningMessages collections. What this means, is that these validators will not have any affect on the valid state of the attribute allowing you to display warning messages even when the attribute is valid.

password: {
  description: 'Password',
  validators: [
    validator('length', {
      min: 4,
      max: 10
    }),
    validator('length', {
      isWarning: true,
      min: 6,
      message: 'What kind of weak password is that?'
    })
  ]
}

Pull Requests

• #226 [Feature] Warning Validators
• #232 [Feature] Computed Options (special thanks to @xcambar)
• #239 [Bug Fix] Use Require for Checking Ember Data
• #240 [Bug Fix] DS Error Validator + Nested Keys

v2.9.3

• #211 Fix regression from last patch by exposing allowNone which defaults to true in length validator

v2.9.1

Please upgrade to v2.9.3 which fixes a regression in this release

• #203 Ember.String.htmlSafe throws exception
• #207 Minor bug fixes
  • Null or undefined value in length validator should be invalid
  • Added parentAttribute to error object to better understand where an error is coming from
  • Added .[] to has-many dependent keys
  • Extend all dependents from Base

Dependents on dependents on dependents

There will be times when your validator will be dependent on some other property or object. Instead of having to include them in your option's dependentKeys, you can declare them in the static getDependentsFor hook. This hook receives two parameters. The first is the attribute that this validator is being added to, and the second are the options there were passed to this validator.

// app/validators/my-custom-validator.js

import BaseValidator from 'ember-cp-validations/validators/base';

const MyCustomValidator = BaseValidator.extend({
  validate() {
    return true;
  }
});

MyCustomValidator.reopenClass({
  getDependentsFor(attribute, options) {
    return ['foo', `${attribute}.bar`];
  }
});

export default MyCustomValidator;

All dependent keys are in reference to the model's validations.attrs object. So when you return ['username'], it will add a dependent to model.validations.attrs.username. If you want to add a dependent on the model, your key needs to be prefixed with _model. So when you return ['_model.username'], it will add a dependent to model.username. This means that if you have a dependent on a service, that service must be injected into the model since returning ['_model.myService.someProperty'] will be interpreted as model.myService.someProperty.

Changes to Tests

Since the CPs now require container/owner access to get all the dependent keys, you will need to add all validators that your unit tests depend on to the needs array in your test module declaration.

moduleForModel('user', {
  needs: ['validator:presence', 'validator:length']
});

v2.8.0

• #161 Alias validator
• #168 Add onOrBefore, onOrAfter, and precision options to date validator @aaronbhansen
• #170 Only call super on validations class if it exists via shouldCallSuper
• #171 Value option
• #171 All Options as Functions methods are now provided with model and attribute
• #173 Add ignoreBlank option to presence validator @krasnoukhov