扩展类进行ajax调用

I am very new to ExtJS 4 and I have a problem extending a class. I have these files:

UsersWindow.js

Ext.define('MyDesktop.UserModel', {
    extend: 'Ext.data.Model',
    /* ... */
}

Ext.define('MyDesktop.UsersWindow', {
    /* ... */
}

DealersWindow.js

Ext.define('MyDesktop.DealerModel', {
    extend: 'MyDesktop.UserModel',
    /* ... */
}

Ext.define('MyDesktop.DealersWindow', {
    extend: 'MyDesktop.UsersWindow',
    /* ... */
}

When I run the application, everything works as expected, however, I have this ajax call:

/UserModel.js?_dc=1379135132790

that gives a 404, and then a error parsing the javascript. I want to understand why ExtJS making this call ? Does every class should be in there own file ? Can I configure ExtJS to no look for this file ?

Thank you for your help.

Yes, every class has to be in its own file for the Ext Loader to work properly. Beside, the name of the file should be the same as the class, and its path should match the namespace.

What happens here is that the extend: 'MyDesktop.UserModel' line prompts the Ext.Loader to load the UserModel class, that it expects to find in the UserModel.js file in the root path for the MyDesktop namespace, which seems to be configured as the root directory of the application...

You can configure root source directories for different namespaces with the paths property of the Loader, or the one of the Application.

If you want to prevent Ext from trying to load this file, you will have to disable the Loader, and then you will have to include all your source files as <script> tags in your HTML. I think this will also make it impossible to compile a production build of the application later.

Alternatively, you could put your definition of MyDesktop.UserModel above the definition of MyDesktop.DealerModel, either in the same file or a file before it in the script tags. Note that even this may not work, because the requires option in your classes definitions may change the order in which the class definition are actually executed. Then again, that will probably break the build process ultimately...

In short, you should not try to work again the framework's expectations. Especially when you consider that the 1:1 mapping between class names and the file system is standard practice in about every OO language out there...