View Full Version : Ext.data.Types problem

17 Oct 2012, 11:40 AM
Having just stumbled upon Ext.data.Types (hardly ever used in official Sencha examples), I started trying to use it in a 2.1 RC1 app. Here's my model file:

Ext.define('OHHChart.model.Datapoint', {
{ name:'week', type:Ext.data.Types.INT },
{ name:'value', type:Ext.data.Types.FLOAT }

When the app runs, it throws an error on the first first field def saying:
<b>Uncaught TypeError: Cannot read property 'INT' of undefined </b>

If I put a breakpoint, I can tell the Ext.data.Types is completely undefined at that point. In case it mattered, I also tried putting Ext.data.Types in the app.js requires. Still same problem.

What am I missing?

19 Oct 2012, 4:52 AM
You should just use strings like 'int' or 'string' and they will be resolved to Ext.data.Types

19 Oct 2012, 6:19 AM
That seems like a step backwards. I always dislike when constants are not constants but strings you have to type over and over and are subject to typos. In any case, it contradicts what's in some of the docs:


19 Oct 2012, 6:26 AM
The issue with using Ext.data.Types is that it's not included in the sencha-touch.js so it has to be dynamically loaded and when you define a model you would have a racing condition to what loads first therefore you have to use a string.

19 Oct 2012, 7:42 AM
I think I see what you're saying. That when you load the js files into the browser, it will try to resolve the config file right away.

But shouldn't putting Ext.data.Types in the requires in the app.js cause it to load before the rest?

Or is the loading process really asynchronous in that it just tells the browser a bunch of things to load and it has no control over which ones come first and just somehow waits until all are finished before executing the applications code?

19 Oct 2012, 7:54 AM
The requires in Ext.application does not guarantee that it is loaded before any model especially with the new Cmd as it does an alpha sort.

19 Oct 2012, 7:57 AM
I see what you're saying. Seems a shame, though. That's one of my least favorite things about Sencha apis, in terms of coding style - all the retyping of strings everywhere, just waiting for you to make a typo each time that can't be caught by your IDE/JSLint/etc.