-
24 Jun 2011 12:22 AM #1
Ext.data.validations presence function return false for numerfields with "0" values
Ext.data.validations presence function return false for numerfields with "0" values
Browsers: Firefox 4.0 and Google Chrome 10.0.648.127.
ExtJs version 4.0.2a.
There is a problem with Ext.data.Model validation type = "presence" when using numberfield. In this case it validation for value "0" is false.
For example this code:
I think presence function does not count cases of int type fields validation.PHP Code:Ext.define('Number', {
extend: 'Ext.data.Model',
fields: [
{name: 'number', type: 'int'}
],
validations: [
{type: 'presence', field: 'number'}
]
});
var instance = Ext.ModelManager.create({
number: 0
}, 'Number');
var errors = instance.validate();
errors.isValid(); //false
errors.getByField('number'); // [{field: 'number', message: 'must be present'}]
-
26 Jun 2011 10:38 AM #2Sencha - Senior Forum Manager
- Join Date
- Mar 2007
- Location
- St. Louis, MO
- Posts
- 33,684
- Vote Rating
- 435
Thank you for the bug report. Please note that we have a new bug template and would appreciate if you could use this from now on.
Mitchell Simoens @SenchaMitch
Sencha Inc, Senior Forum Manager
________________
http://www.JSONPLint.com - Source to lint your JSONP!
Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
https://github.com/mitchellsimoens
Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/
Need more help with your app? Hire Sencha Services services@sencha.com
Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is almost in print!
When posting code, please use BBCode's CODE tags.
-
4 Jul 2011 12:23 PM #3
Just ran into the same problem
REQUIRED INFORMATION Ext version tested:- Ext 4.0.2a
- FF4 (firebug 1.7 installed)
- Presence Validator fails if value is zero
- Define a model validator with presence validator for a field
- Field value to validate is (int) 0
- The validator should return "true" because zero can be a wanted value for a field (like numberfield)
- Validator returns "false"
HELPFUL INFORMATION Debugging already done:Code:Ext.define('Number', { extend: 'Ext.data.Model', fields: [ {name: 'number', type: 'int'} ], validations: [ {type: 'presence', field: 'number'} ] }); var instance = Ext.ModelManager.create({ number: 0 }, 'Number'); var errors = instance.validate(); errors.isValid(); //false errors.getByField('number'); // [{field: 'number', message: 'must be present'}]- in Ext.data.validations, the method "presence" is using "!!value", which is false if value is 0
- example: !!0 === false
- in Ext.data.validations.presence():
- maybe "return !Ext.isEmpty(value)" ?!
/**
* Validates that the given value is present
* @param {Object} config Optional config object
* @param {Mixed} value The value to validate
* @return {Boolean} True if validation passed
*/
presence: function(config, value) {
if (value === undefined) {
value = config;
}
return !Ext.isEmpty(value);
},
- Ubuntu 10.10
//edit: Oh, there is already a bug id for this, did not see that
//edit2: if you don't want to change the Ext source, you can use a format validator as a temporary fix
PHP Code:validations: [
{type: 'format', field: 'number', matcher: /^\d+$/}
]
-
25 Jul 2011 10:46 AM #4
I can confirm this is an issue in 4.0.4, the presence method for what ever reason is return the value of the field rather than a true so if the field is an int with a zero or a boolean value of false it will always fail. Looking at the other validation methods they are returning either true or false, however the presence method returns either the value on success or the config on failure which seems inconsistent with the other validation methods.
-
25 Jul 2011 11:14 AM #5Sencha - Community Support Team
- Join Date
- Jan 2009
- Location
- Palo Alto, California
- Posts
- 1,941
- Vote Rating
- 6
Thanks, this is now fixed in the 4.1.0 branch
Ext JS Senior Software Architect
Personal Blog: http://edspencer.net
Twitter: http://twitter.com/edspencer
Github: http://github.com/edspencer
Success! Looks like we've fixed this one. According to our records the fix was applied for
EXTJSIV-3325
in
4.0.6.


Reply With Quote