Success! Looks like we've fixed this one. According to our records the fix was applied for
a recent build.
Ext JS Premium Member
[4.1.2] Controller classes not in a 'controller' namespace fail during class creation
Ext version tested:
- 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
controllers: [ 'MyApp.a.name.space.MyController' ]
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.
Ext JS Premium Member
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
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.
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
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.
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:
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.