The problem is that the compiler needs to understand the object parameter that goes to Ext.application. It does not do data-flow analysis to track that down so it would not understand anything on the "config" object passed to Foo.application (such as "requires", "models", etc).
I'll throw out a few ideas off-hand and you can see if any fit for you...
You could move "// ... some special Foo code here" to either Foo.app.Application constructor or onBeforeLaunch. This makes the value-add part of the derived class entirely and Ext.application would still do the final construction/configuration.
Or you could move things out of the "config" object you pass in to its own class derived from Foo.app.Application. The config object would really then only have the "extend" to name your derived class.
Or you could split the special logic into its own method and call it before Ext.application.
Or you could place the logic in a class extend hook:
Code:
Ext.define('Foo.app.Application', {
onClassExtended: function(cls, data) {
// some special Foo code here
}
});
The above code will be called when the derivation occurs (before onReady) and you will have the derivation body ("data") to examine.
Of course, standard cautions apply to doing things before the DOM is ready. Putting the special logic in the constructor or onBeforeLaunch is typically a better choice.
FYI
Here's what Ext.application is looking like so far (but not 100% final yet):
Code:
Ext.application = function(config) {
var App;
// Let Ext.define do the hard work but don't assign a class name.
//
Ext.define(null, Ext.apply({
extend: 'Ext.app.Application' // can be replaced by config!
}, config),
// call here when the App class gets full defined
function () {
App = this;
});
Ext.onReady(function() {
// this won't be called until App has been created and its requires have been
// met...
Ext.app.Application.instance = new App();
});
};
This means that your constructor is no longer called before-ready which is typically ideal.
Anyway, just some thoughts.