Custom Validators in ST2 / Architect 2.1

[Sottilde]

It looks like the simple support for adding a validator to a Form field is not present in ST2, while it is in ExtJS4.

Information I've found online suggests to add validators to your models, and validate the model instead. That's fine.

Unfortunately the included validations are not enough for me - I need extras (e.g. credit card).

I added the following code and included it directly in my index.html:

Ext.applyIf(Ext.data.Validations, {    creditCard: function (config, value){
        if(arguments.length === 1) value = config;


        value = value.replace(/[\s\-]+/g, "");
        // Match Visa, Diner's Club / Mastercard, Amex, Discover
        return (/^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11})$/).test(value);
    },
    creditCardMessage: 'is not a valid credit card'
});

Unfortunately, there doesn't appear to be any way to use this validator in my model, short of overriding the entire model. And since overrides aren't playing nice with the SDK tools, I'd like to avoid that. Any other options?

[Sottilde]

Also - the "Format Validation" is missing the "matcher" attribute.

[Sottilde]

Sorry to push on this, but I have a CC# form that has to be validated and this is making it very difficult. Does anyone have any ideas?

[ssamayoa]

Sorry to push on this, but I have a CC# form that has to be validated and this is making it very difficult. Does anyone have any ideas?

It seems that you want to validate credit car numbers,

Write a custom Text field to do that which not only validates the format but also the check digit.

For example, I "ported" the password confirm from examples to custom component:

Ext.define('VCI.view.override.PasswordConfirm', {
	override: 'VCI.view.PasswordConfirm',
	vtype: 'password'
}, function() {
	Ext.apply(Ext.form.field.VTypes, {
		password : function(val, field) {
			if (field.initialPassField) {
				var container = field.up('form');
				if (!container) {
					container = field.up("container");
				}
				var pwd = container.down('#' + field.initialPassField);
				if (!pwd) {
					pwd = container.down('[name=' + initialPassField + ']');
				}
				return (val == pwd.getValue());
			}
			return true;
		},
		passwordText : 'La contraseña no coincide',
	});
});

Generated code:

/*
 * File: app/view/PasswordConfirm.js
 *
 * This file was generated by Sencha Architect version 2.0.0.
 * http://www.sencha.com/products/architect/
 *
 * This file requires use of the Ext JS 4.1.x library, under independent license.
 * License of Sencha Architect does not include license for Ext JS 4.1.x. For more
 * details see http://www.sencha.com/license or contact license@sencha.com.
 *
 * This file will be auto-generated each and everytime you save your project.
 *
 * Do NOT hand edit this file.
 */


Ext.define('VCI.view.PasswordConfirm', {
	extend: 'Ext.form.field.Text',
	alias: 'widget.passwordconfirm',


	requires: [
		'VCI.view.override.PasswordConfirm'
	],


	initialPassField: '',
	inputType: 'password',


	initComponent: function() {
		var me = this;


		me.callParent(arguments);
	}


});

Regards.

[Sottilde]

Yes, I was hoping to do this without overrides, however; the overrides system in SA2.1 is somewhat broken, as I detail in another thread.

I believe the best way to do this may be just to put a keyup handler on the field that essentially throws validation errors on the model manually. It is a shame that there isn't a generic way to add validators in SA2.1; it is quite easy to do in code.

[ssamayoa]

I believe the best way to do this may be just to put a keyup handler on the field that essentially throws validation errors on the model manually.

I don't agree with you.

If you craft your specialized components like the one you need now (credit card input with validation) you enforces the DRY principle. Each time you need a credit card just reuse the component instead of writing it again or copy/paste the code.

In the example I gave to you, how many times I will use it in an application?

Is almost save to say: one, when user change its password.

But, do I will need it in every application I will write in the future? May be all of them unless there is no authentication in some of them.

Regards.

[Sottilde]

I don't agree with you.

If you craft your specialized components like the one you need now (credit card input with validation) you enforces the DRY principle. Each time you need a credit card just reuse the component instead of writing it again or copy/paste the code.

In the example I gave to you, how many times I will use it in an application?

Is almost save to say: one, when user change its password.

But, do I will need it in every application I will write in the future? May be all of them unless there is no authentication in some of them.

Regards.

I agree, and this is how I would code it in a perfect world, but SA2.1 has broken support of overrides when using the build tools. I either have a working build or an override, but not both.

[ssamayoa]

I agree, and this is how I would code it in a perfect world, but SA2.1 has broken support of overrides when using the build tools. I either have a working build or an override, but not both.

And because overrides is "broken" in the Sencha sdk (lets discus that later) you prefer not to enforce DRY? Sorry but you can easily overcome the limitation in the SDK just including, by hand or automated, the needed code/js files to work with build.

Regards.

[Sottilde]

And because overrides is "broken" in the Sencha sdk (lets discus that later) you prefer not to enforce DRY? Sorry but you can easily overcome the limitation in the SDK just including, by hand or automated, the needed code/js files to work with build.

Regards.

I don't understand the need for this debate. I have a credit card validator working just fine in my Ext4 version. 90% of that code will work fine in a keyup handler. And I have written an extension to Ext.data.Validations, I just don't have a way to add it to my model without overriding it and breaking my build. And yes, it is broken, much like most of the Sencha SDK - I have spent quite a bit of time with this.

In any case the "right" way to do this is to add it to Ext.data.Validations, and it is not much than 3 lines of code. In fact, I have spent far more time replying to your insistence that I enforce DRY than I would ever spend copying/pasting this hack.

[ssamayoa]