[4.1.2] Controller classes not in a 'controller' namespace fail during class creation

[damien]

REQUIRED INFORMATION


Ext version tested:

• 4.1.2

Description:

• A custom class extending from Ext.app.Controller in a namespace that does **not** follow the pattern /^(.*)\.controller\./ will fail during class creation in Ext.app.Controller#onClassExtended

Steps to reproduce the problem:

• Create a custom controller class, extending Ext.app.Controller
• in a namespace that does not include 'controller' before the class name, e.g. MyApp.a.name.space.MyController

The result that was expected:

• ...

The result that occurs instead:

• Fails during class creation

Test Case:

Ext.define('MyApp.a.name.space.MyController', {
   extend: 'Ext.app.Controller'

});
Ext.application({
   appName: 'MyApp',
   controllers: [ 'MyApp.a.name.space.MyController' ]
});

[mitchellsimoens]

If the controller is in it's own file it will work. The reason is because it needs to have the path set for the appName and at the time the Ext.define is fired for your controller, the path isn't setup because Ext.app.Application hasn't been created either.

[damien]

It is correct that it will work in a development setup with Ext.Loader configured.

It will not work in a production setup.

This bug was introduced in 4.1.2, it worked in 4.1.1

[mitchellsimoens]

Looking at the code, isn't all the code in the onClassExtended for development? It sets up what should go in the Ext.require which should all be loaded already in a production build.

[mberrie]

That's a good point. What is the relevance of dependencies in a production scenario with all javascript sources loaded manually and Ext.Loader disabled? Does it still affect the class loading system?

I guess it does because dependencies are not only relevant as a means of loading file resources, they also affect the class loading (=creation) order I would assume. That is probably more true for a class that defines dependencies via 'requires' than it is for dependencies defined via 'uses' or plain 'Ext.require' statements.

However, this assumption is rather based on logical conclusions derived from how other class dependency loading schemes work than it is based on knowledge of the actual implementation of Ext.ClassManager

[mitchellsimoens]

When doing a build, it of course will look at all the classes required and will build them into 1 file. You then include that file in the production index.html (or whatever you use) and when that file is loaded by the browser the classes are defined. They are now ready to have instances created.

[mberrie]

It seems that Ext.define goes straight through to Ext.Loader for dependency loading. If Ext.Loader is disabled, a missing dependency will cause the class loading to fail.

This will fail:

Ext.define('A', {
requires: 'B'
});
Ext.define('B', {});

While it might seem obvious that this is not going to work, it could as well have been supported assuming that classes will only be available in 'Ext.onReady'. Classes with missing dependencies could be queued until the dependency is available. A missing dependency would cause a failure only if not resolved until 'documentReady'.

However, I don't want to imply that this is a desired feature. I was merely openly thinking about the behavior of Ext.ClassManager in a production environment.