Sencha Cmd integration questions

[johnyanarella]

@superstructor - I have a couple questions I haven't yet had a chance to investigate re: the Sencha Cmd integration work you've done. On Friday, I intend to migrate a couple projects over from the Sencha SDK Tools to Sencha Cmd, so I'll probably discover the answer to these questions then. That said, I'm curious if you already know the answers.

• You mentioned that referencing the Deft JS package as a requirement in your Sencha Cmd based projects automatically adds the Deft JS classes to the classpath. Do you still currently have to manually require Deft.Class, Deft.mixin.Controllable, etc.?
• If so, is there a way we can leverage the Sencha Cmd package 'overrides' feature to ensure the controller and inject class preprocessors are automatically required and registered - after the Ext JS or Sencha Touch code is loaded but before any application code is loaded?

NOTE: In Deft JS v0.9.5, the mixins (which at this point only emit the deprecated message) will likely be removed, and the class preprocessor registration logic will move to a different package.

Thoughts?

[superstructor]

Yes you still have to manually require Deft classes that you use. Currently I require Deft.ioc.Injector and Deft.mixin.Controllable in app.js or MyApp.Application class so its only needed in one file, not everywhere that depends on it.

Overrides are automatically included in the build so may be possible to leverage that to avoid the manual require statements. I'll do some tests and get back to you.

[johnyanarella]

I just tried to integrate the new Deft JS Sencha Cmd package into a Sencha Touch application. As far as I can tell, it appears that packages are only considered during the build process. The development microloader reads in app.json but ignores the requires block.

I think this means that in order to support development mode, we'll still have to ask developers to paste in some bootstrapping code (guarded by //<debug> and //</debug> comments) to require necessary Sencha classes and configure Ext.Loader to point to packages/deft/src/js. Is this what you were doing for development mode, or am I missing something?

Thanks!

[johnyanarella]

For example, modifying the default app.js like so:

//<debug>
Ext.Loader.setPath({
    'Ext': 'touch/src',
    'Deft': 'packages/deft/src/js',
    'MyApp': 'app'
});

Ext.syncRequire(['Deft.mixin.Injectable','Deft.mixin.Controllable']);
//</debug>

will make things work in development mode.

If developers are going to have to explicitly reference Deft JS class requirements in development mode in order to enable the inject and controller class preprocessors, I view this as further evidence that I should go ahead and separate the class preprocessors out from those deprecated mixin definitions sooner rather than later.

@brian428 and @superstructor - curious your vote on the names / packages for these separated preprocessor class files. I'm thinking:

• Deft.ioc.InjectClassPreprocessor
• Deft.mvc.ControllerClassPreprocessor

and a new:

• Deft.core.ClassPreprocessors

that includes automatically includes both of the above.

So, most developers would just do:

Ext.syncRequire(['Deft.core.ClassPreprocessors']);

But advanced developers could still specify only the preprocessors (and their dependencies) that they want to use. For example:

Ext.syncRequire(['Deft.mvc.ControllerClassPreprocessor']);

Alternatively, similar to the Deft.core.ClassPreprocessors idea, we could just include a bootstrapping class that includes both preprocessors today, but might include other kinds of setup logic in the future. Not sure what to call that class.

Thoughts?

[superstructor]

Yes thats correct currently the class path is only fully automatic for production builds i.e. sencha app build.

For development mode you can either

1. sencha app refresh to update the class path metadata for development mode.
2. do exactly as you have done in your example with Ext.Loader.

Sorry to have missed outlining how development mode works with Sencha Cmd packages until now.

Going to breakfast :-) will respond to remaining questions in the next couple of hours.

[johnyanarella]

No problem - thanks for the insight.

Any idea where that class path metadata is stored for development mode? I had tried that command (and just tried it again) and it had no effect for my Sencha Touch project.

[superstructor]

In Ext JS this "metadata" is stored in the Sencha Cmd generated file bootstrap.js that is included by default in index.html.

It just looks like this:

Ext.Loader.addClassPathMappings({
  "Deft": "../packages/deft/src/js"
});
Ext.ClassManager.addNameAlternateMappings({
  "Deft.ioc.Injector": [
    "Deft.Injector"
  ]
});

I.e. almost exactly the same as what you'd do manually with Ext.Loader plus it adds class aliases like Deft.Injector as alternate class names so those also work for module loading.

Now interestingly as you've found sencha app refresh appears to do absolutely nothing for Sencha Touch. At least as observed by GIT there are no changes. Looking at microloader/development.js I can't see anything that refers to automatically setting up the class path or using the requires array in app.json.

I think this should be raised as a bug with Sencha, thoughts ?

[johnyanarella]

Good to know. I guess this explains why packages aren't documented yet for Sencha Touch!

Hopefully we can sit down with some of the Sencha engineers at SenchaCon to share our pain points and get a better sense of where this is going.

[superstructor]

Both Ext JS and Sencha Touch have a @require @packageOverrides line in app.js. I'm still testing how this can be leveraged, if at all, to automatically require the class preprocessors.

[superstructor]

Re naming I think either

1

Deft.ioc.InjectableClassPreprocessor
Deft.mvc.ControllableClassPreprocessor

or alternatively

2

Deft.ioc.InjectorClassPreprocessor
Deft.mvc.ViewControllerClassPreprocessor

I prefer 1. as these are the preprocessors for injectable and controllable classes.

[johnyanarella]

Interesting. Of those two, I prefer the first.

My suggested naming was derived from the particular keyword (i.e. 'inject' and 'controller') those preprocessors process.

[johnyanarella]

The last few items of discussion here are no longer relevant.

In the next release, we'll be moving back to using mixins, since class preprocessors are not supported by the Sencha Cmd class optimizer (now enabled by default for Ext JS).