View Full Version : Sencha Cmd and custom Ext.application

1 Oct 2012, 1:32 PM
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.

2 Oct 2012, 12:16 AM
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:

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.

2 Oct 2012, 10:39 AM
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) {

// ... some special Foo code here

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

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

3 Oct 2012, 1:09 AM
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.

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

4 Oct 2012, 2:06 PM
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.

5 Oct 2012, 4:16 PM
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?

5 Oct 2012, 4:29 PM
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.

5 Oct 2012, 4:49 PM
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?

5 Oct 2012, 5:27 PM
Yeah you're right, I think I was confused. Thanks for indulging me.