States for validation results about meteor-simple-schema HOT 6 CLOSED

Sounds good conceptually, but do you have thoughts about how it could be implemented? Not everyone has the same idea about what should be error vs. warning vs. info. Also, purely visual distinctions might fit better in the autoform package, such as adding a afFieldErrorType helper, which could be used with #if to add error/warning/info class.

from meteor-simple-schema.

I was thinking the validation states should be defined in the schema, and then displayed with something like a afFieldState helper class. Perhaps custom messages and states could be set with an object, while still supporting the existing API. For example:

UserSchema = new SimpleSchema({
  username: {
    type: String,
    label: "Username",
    regEx: /^[-_a-z0-9]*$/i,
    unique: { value = true, message = "That username is already taken." },
    min: { value = 2, message = "One character usernames are boring", state = "warning" }
  },
  password: {
    type: String,
    label: "Password",
    min: 8,
    regEx: [
      /[a-z]/i,
      { value = /[0-9]/, message = "[label] must have some numbers." },
      { value = /[^a-z0-9]/i, message = "[label] could use a symbol or two.", state = "warning" }
    ]
  }
});
UserSchema.successStates(['success', 'warning']);

The default states would be 'success' and 'error'. Perhaps special 'required' (erroneous) and 'optional' (successful) states could be used on the client when the input is empty.

It also shows an idea for supporting multiple regex formats, each with the ability to use custom messages and validation states, if desired.

from meteor-simple-schema.

Generally this is in the right direction, but a few points:

Point 1:
Custom messages are already possible in the current API with messages() method. I know there is a temptation to want them in the schema, but for I18N and multi-language reasons, it's best to set those separately so that they can be easily changed dynamically.

Point 2:
The separation between the packages is not always evident without digging into the code, but to put it simply, the simple-schema package blindly checks an object against a schema, without caring about things such as UI, collections, inserts, updates, etc. It makes note of the first error it finds for each field, and then collection2/autoform packages decide what to do with that error list. However, it's fine for the other packages to use the schema definition object as a place for defining additional information, such as the unique option that collection2 uses.

So my point is that it might make sense to define error states in the schema object (or something similar), but I don't think the simple-schema package necessarily needs to know anything about them. I'm trying to think through the various use cases, and I really can only think of one reason for having them: to indicate to a user that a property's value is not ideal while still technically passing validation (i.e., allow submission, insertion, etc.). In other words, it has nothing to do with validity. It should be thought of as more of a user-assistance feature.

With all that in mind, it seems to me like a separate "warning schema" implemented by the autoform package is a better way to think about it. In other words, you could specify a SimpleSchema defining some additional schema rules that should be displayed and treated as warnings. These would only be tested prior to form submission. Here's one possible implementation:

JS:

UserForm = new AutoForm({
  username: {
    type: String,
    label: "Username",
    regEx: /^[-_a-z0-9]*$/i,
    unique: true
  },
  password: {
    type: String,
    label: "Password",
    min: 8,
    regEx: /[a-z0-9]/i
  }
});

UserFormWarnings = new SimpleSchema({
  username: {
    type: String,
    label: "Username",
    min: 2
  },
  password: {
    type: String,
    label: "Password",
    regEx: /[^a-z0-9]/i
  }
});

Template.insertUserForm.warningSchema = function () {
  return {
    warning: {
      check: UserFormWarnings,
      on: "keyup" //could be either "keyup" or "blur"
    }
  };
};

HTML:

<template name="insertUserForm">
    {{#autoForm schema="UserForm" additionalSchemas=warningSchema id="insertUserForm"}}
        <div class="form-group{{#if afFieldIsInvalid 'username'}} has-error{{/if}}{{#if afFieldIsInvalid 'username' type="warning"}} has-warning{{/if}}">
            {{afFieldLabel 'username'}}
            {{afFieldInput 'username'}}
            {{#if afFieldIsInvalid 'username'}}
            <span class="help-block">{{afFieldMessage 'username'}}</span>
            {{/if}}
            {{#if afFieldIsInvalid 'username' type="warning"}}
            <span class="help-block">{{afFieldMessage 'username' type="warning"}}</span>
            {{/if}}
        </div>
        <div class="form-group{{#if afFieldIsInvalid 'password'}} has-error{{/if}}{{#if afFieldIsInvalid 'password' type="warning"}} has-warning{{/if}}">
            {{afFieldLabel 'password'}}
            {{afFieldInput 'password'}}
            {{#if afFieldIsInvalid 'password'}}
            <span class="help-block">{{afFieldMessage 'password'}}</span>
            {{/if}}
            {{#if afFieldIsInvalid 'password' type="warning"}}
            <span class="help-block">{{afFieldMessage 'password' type="warning"}}</span>
            {{/if}}
        </div>
    <button type="submit" class="btn btn-primary insert">Insert</button>
    {{/autoForm}}
</template>

Each of the afField... helpers would accept an optional type attribute, which would link it up with that defined schema instead of the default validation schema. One or more of these would be defined in an object passed to additionalSchemas on the autoform helper.

from meteor-simple-schema.

I agree with you @aldeed, warning messages should be implemented in the AutoForm package.

About the API I'm not sure but I think that Meteor UI will introduce the concept of component which is a kind a template where you can define some custom methods on it. For instance a field component could have a warn method, something like that:

Template.myFormTpl.events({
    'keyup #passwordInputId': function(event) {
        var self = this; // this is the component object
        var value = event.currentTarget.value; // or this.value?
        if (value.length < 5)
            self.warn("You should use a longer password")
        if ((/[^a-z]/i).test(value))
            self.warn("You should use numbers for better security");
    }
});

from meteor-simple-schema.

That's a good point, @mquandalle. I don't know if the Meteor UI API is firm yet, but that's something to figure out as soon as that is released.

from meteor-simple-schema.

Ah, yes, multiple schemas for extra states would probably be a better way of solving the problem.

from meteor-simple-schema.