[FIXED-188][3.1.1] Undocumented annoyances Ext.data.Field (3.0 -> 3.1.1)

[bone]

Hello!

Ext.data.Field seems to have undergone some hidden changes from 3.0 to 3.1.1.

In 3.0 one could use the types 'integer' and 'boolean':



// excerpt DataField.js from Ext 3.0
case "int":
case "integer":
cv = function(v){
return v !== undefined && v !== null && v !== '' ?
parseInt(String(v).replace(stripRe, ""), 10) : '';
};
break;
case "float":
cv = function(v){
return v !== undefined && v !== null && v !== '' ?
parseFloat(String(v).replace(stripRe, ""), 10) : '';
};
break;
case "bool":
case "boolean":
cv = function(v){ return v === true || v === "true" || v == 1; };
break;
case "date":


Whereas in 3.1.1 I just spent an hour trying to figure out why ***t wasnt working, and it all boiled down to :



// excerpt DataField.js from Ext 3.0
case "int":
cv = function(v){
return v !== undefined && v !== null && v !== '' ?
parseInt(String(v).replace(stripRe, ""), 10) : '';
};
break;
case "float":
cv = function(v){
return v !== undefined && v !== null && v !== '' ?
parseFloat(String(v).replace(stripRe, ""), 10) : '';
};
break;
case "bool":
cv = function(v){ return v === true || v === "true" || v == 1; };
break;


I wouldnt mind these changes if I was aware of them!

Also, to top it of, the current api-docs for Ext.data.Field (http://www.extjs.com/deploy/dev/docs/?class=Ext.data.Field) says:

type : String
The data type for conversion to displayable value if convert has not been specified. Possible values are
auto (Default, implies no conversion)
string
int
float
boolean
date

[alexb]

Could the team put "integer" and "boolean" back? It will help with converting apps from 2.x to 3.1.x

This is yet another reason to ask when 3.1.2 is going to be released...

[VinylFox]

Your not alone.

http://www.extjs.com/forum/showthread.php?t=91253
http://www.extjs.com/forum/showthread.php?p=425667

[bone]

Personally I wouldn't go as far as calling it a 'bug'.

I was just posting this to start a discussion about undocumented annoyances. I am a little disappointed over the lack of forseeing possible implications and hours spent for your customers debugging two missing case-lines in a switch.

Especially when it is logged as cryptic as:

References #188. Revert this issue after comments by Animal, that "data-type" should be normalized. When generating DataReaders with serverside-code, that code will simply adhere to the Ext data-types.

But on the other hand, hindsight is always 20-20?


~o)

[Animal]

I went out of my way in that comment to say that when specifying types that addition to 3.0 to allow "int" or "integer" would be a good idea.

But that after construction, the type should be normalized to a single, predictable value. ie booleans should have type "boolean", integers should have type "integer". In fact there should be an Ext.data enumeration somewhere so that in fact the types are



Ext.data.Type.BOOLEAN,
Ext.data.Type.INTEGER
etc...

[mystix]

Ext.data.Type.BOOLEAN,
Ext.data.Type.INTEGER
etc...


+1 to this Very Good Idea.

[evant]

Nige's suggestions have been implemented in the 3.2.x branch, there's now a new Ext.data.Types class. There's a minor breaking change, interrogating field.type will now return an object data type.

The stripRe has also been included for i18n so it can be overridden in a locale file.

Of course there's also the advantage you can now declare your own types!

[jburnhams]

I've also just came across this bug. It took me a lot longer to fix as the live docs (http://www.extjs.com/deploy/dev/docs/?class=Ext.data.Field) still state you should use 'boolean' and don't mention 'bool'.