Sencha Cmd and custom Ext.application

[paul_wang]

It looks like Sencha Cmd can recognize Ext.application and add implicit dependency for Ext.application call. The problem is that we're using a custom namespace and have our own Foo.application call that mimics the Ext.application function. Is it possible to tell Sencha Cmd that a particular function is equivalent to Ext.application?

This is for Sench Cmd 3.0.0-181 on windows. Thanks.

[dongryphon]

We have a fix planned for 4.1.3 that will move the logic from Ext.application to the standard derivation mechanism from Ext.app.Application to resolve some of these issues.

This will enable this to work:

   Ext.application({
       extend: 'Foo.bar.BasicApp',
       ...
   });

Internally this will create a derived class from Foo.bar.BasicApp so this would be a way to provide common functionality at the app level (e.g., to provide commonality in across dev teams).

I'm afraid this part of the compiler is already pretty complex so we'd really rather find a more OO way to address the problem. Would the above give you a place to perform your value-add?

If not and you want to elaborate on what your wrapper does, maybe we can help find a good solution.

[paul_wang]

Our code looks something like this. We're using our own namespace and because Ext.application is a function I didn't think the code you provided would work but perhaps I should look into that..

Foo.app.Application does extend Ext.app.Application so would this work in 4.1.3?

Foo.application = function(config) {
    Ext.require('Foo.app.Application');

    // ... some special Foo code here

    Foo.onReady(function() {
        Ext.create('Foo.app.Application', config);
    });
};

Instead of Ext.application(...) we would then do Foo.application(...).

[dongryphon]

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:

    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):

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.

[paul_wang]

Thanks for the various options. We can work around the issue today using //@requires Foo.model.* so the various application files get pulled in. Will look at this again when 4.1.3 is available.

This is sort of off topic but looking at that 4.1.3 snippet wouldn't there be a race condition if there's no require in the application? Wouldn't Ext.onReady fire the callback immediately and there's no guarantee that the line App = this; has been executed already.

[dongryphon]

The "extend" is a form of "requires" and will request Ext.app.Application (or other class based on config.extend) so the loader will have to fetch Ext.app.Application at a minimum.

Does that address your concern?

[paul_wang]

But if I'm using ext-all.js then the Loader will not have to load Application.js which means it'll call the callback immediately. I'm not very familiar with if there's a lag between Ext.define and when createdFn gets called so I don't know if that's an issue or not.

[dongryphon]

In that scenario, the createFn on the class should fire immediately since all requirements are met.

If the onReady fires immediately, that would be wrong since we aren't domready yet. Is that happening in the current version?

[paul_wang]

Yeah you're right, I think I was confused. Thanks for indulging me.