Replacing SDK v2 with Cmd v3

Hi,

Trying to get an app building in using the new Sencha Cmd v3, and having issues.
Can't seem to get a decent error message out of it...

I have a three stage process:
Make symlinks so that filesystem looks like web structure.

Create JSB3

Build it

In SDK Tools v2 creating the JSB3 used:

Code:

sencha create jsb -a http://localhost/TransferGateway/index_build.html -p ATG.jsb3

Now I'm trying (in Cmd v3):

Code:

sencha --debug app resolve -uri http://localhost/transfergateway/index_build.html -output-file ATG_cmd3.jsb3

Getting output:

Code:

Sencha Cmd v3.0.0.250 [ERR] null com.sencha.exceptions.BasicException at com.sencha.exceptions.BasicException.wrap(BasicException.java:43) at com.sencha.cli.Command.dispatch(Command.java:104) at com.sencha.cli.Commands.dispatch(Commands.java:49) at com.sencha.cli.Commands.dispatch(Commands.java:49) at com.sencha.command.Sencha.main(Sencha.java:71) Caused by: java.lang.NullPointerException at com.sencha.command.app.AppCommands$ResolveCommand.execute(AppCommands.java:197) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sencha.cli.Command.dispatch(Command.java:78) ... 3 more

I have no idea how I'm going to do the next step, building the JSB3.
Trying to point it at an older version either does nothing or give me:

Code:

[ERR] Please ensure this command was executed from a valid application directory [ERR] Unable to locate 'app.dir' config property from sencha.cfg

I do not use Sencha Architect, this is an existing product.
Can I generate an app.dir or something? What is its format?

Appreciate any help.

Cheers,
Westy

Step 2 is the issue... Cmd does not produce JSB3 files but does have support for building from them if you have a process for maintaining them.

The compiler picks up configuration from the ".sencha/app/sencha.cfg" file but that is not required to use the compiler.

I would start here on the guides: http://docs.sencha.com/ext-js/4-1/#!...and_app_single

If you have specific questions about your app structure, feel free to elaborate.

Probably should mention that Cmd compiles from sources and not a running instance. This workflow from v2 was quite a problem for lots of folks... it was tricky to have to run your app in order to build your app.

Quote:

Originally Posted by dongryphon

Probably should mention that Cmd compiles from sources and not a running instance. This workflow from v2 was quite a problem for lots of folks... it was tricky to have to run your app in order to build your app.

Does it still analyse what classes are actually referenced, to build the minimum set it can?

Thanks for the info by the way.

I must say this looks like a step back for us. Yes, actually loading the site from the filesystem required some messing about with symlinked directories to make the structure the same as the web site, and this may not be simple for some, but it's quite a nice way of producing a list of all referenced classes that can then be built.

Having all the source in the single html is not really going to work for us.
We already have the concept of a bootstrap file, into which goes the path configuration that clients may want to tinker with.

To illustrate, our index_build.html:

Code:

<!doctype html> <html> <head> <meta http-equiv="X-UA-Compatible" content="IE=10,chrome=1"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">  <script type="text/javascript" src="lib/Ext/4.1.3/ext-dev.js"></script> <script type="text/javascript"> // Set up dynamic class loader Ext.Loader.setConfig({ enabled: true, disableCaching: false }); </script>  <script type="text/javascript" src="lib/js/log4javascript/log4javascript-1.4.1/log4javascript.js"></script>  <script type="text/javascript" src="bootstrap_build.js"></script> </head> <body/> </html>

And an example of our bootstrap:

Code:

(function() { Ext.define('Altus.Products.Product1.Constants', { singleton: true, extRoot: 'lib/Ext/4.1.3', commonRoot: 'Common', product2Root: 'Product2', product2RootForServices: '/Product2', productName: 'Product 1', themeName: 'altus-blue', defaultBatchRequests: 10, defaultMaxRetries: 5, defaultTimeout: 10000, retryTimeFactor: 2, timeoutLimit: 300000 }); Ext.define('Altus.Products.Product2.Constants', { singleton: true, defaultBatchRequests: 10, defaultMaxRetries: 5, defaultTimeout: 3000, retryTimeFactor: 2, timeoutLimit: 300000 }); // Configure the dynamic class loader Ext.Loader.setPath('Common', Altus.Products.Product1.Constants.commonRoot + '/app'); Ext.Loader.setPath('Altus.Products.Product2', Altus.Products.Product1.Constants.product2Root + '/app'); Ext.Loader.setPath('Altus.Products.Product1', 'app'); Ext.Loader.setPath('Ext', 'src'); Ext.Loader.setPath('Ext.ux', Altus.Products.Product1.Constants.extRoot + '/examples/ux'); // Disable Fx if we're in an old browser if (Ext.isIE && !Ext.isIE9) { if (Ext.isDefined(Ext.global.console)) { Ext.global.console.warn('IE8 or below, disabling Fx...'); } Ext.enableFx = false; } // Now sort our includes... // Favicon document.write('<link rel="shortcut icon" type="image/x-icon" href="' + Altus.Products.Product1.Constants.commonRoot + '/resources/images/favicon.ico" />'); document.write('<link rel="icon" type="image/ico" href="' + Altus.Products.Product1.Constants.commonRoot + '/resources/images/favicon.ico">'); // Including our framework fixes here means that we cannot change Ext.define, but that's pretty unlikely anyway... // FIXME: We may want to use Ext.Loader to load additional scripts, see: http://www.sencha.com/forum/showthread.php?176555-Loading-a-script-file document.write('<script type="text/javascript" src="' + Altus.Products.Product1.Constants.commonRoot + '/app/FrameworkFixes.js"></script>'); // CSS // Our Ext theme document.write('<link rel="stylesheet" href="' + Altus.Products.Product1.Constants.commonRoot + '/resources/css/ext-all-' + Altus.Products.Product1.Constants.themeName + '.css" type="text/css">'); // Our own styles document.write('<link rel="stylesheet" href="' + Altus.Products.Product1.Constants.commonRoot + '/resources/css/altus.css" type="text/css">'); document.write('<link rel="stylesheet" href="' + Altus.Products.Product1.Constants.product2Root + '/resources/css/ams.css" type="text/css">'); document.write('<link rel="stylesheet" href="resources/css/atg.css" type="text/css">'); // Ext.Direct handlers document.write('<script type="text/javascript" src="' + Altus.Products.Product1.Constants.product2RootForServices + '/Services/Json/AuthenticationServiceHandler.ashx"></script>'); document.write('<script type="text/javascript" src="' + Altus.Products.Product1.Constants.product2RootForServices + '/Services/Json/TokenGenerationServiceHandler.ashx"></script>'); document.write('<script type="text/javascript" src="' + Altus.Products.Product1.Constants.product2RootForServices + '/Services/Json/TokenInformationServiceHandler.ashx"></script>'); document.write('<script type="text/javascript" src="Services/Json/ServiceHandler.ashx"></script>'); // The ATG application class document.write('<script type="text/javascript" src="app/Application.js"></script>'); // Set the page title document.title = "Altus " + Altus.Products.Product1.Constants.productName; }());

I think will have to keep using v2 for now, and hope that either it continues to work, or that you add support for the phantomjs method to v3.

Any thoughts?

Cheers,
Westy

Quote:

Originally Posted by westy

Does it still analyse what classes are actually referenced, to build the minimum set it can?

Definitely yes - that is the whole purpose of a build. :)

The difference is that Cmd does this by reading your sources and parsing them into syntax trees and then looks for "requires" and "uses" (and the rest) to determine dependencies. Unlike v2, Cmd respects conditional dependencies as well, that is those wrapped in <debug> or <if> comments like so:

Code:

Ext.define('MyApp.foo.Bar', { requires: [ //<debug> 'Ext.diag.*', //</debug> 'Ext.grid.Panel' ], ... );

Quote:

Originally Posted by dongryphon

Definitely yes - that is the whole purpose of a build. :)

Ok, that's good to know.
Perhaps I'll revisit when I have time.

My application is properly laid out in the suggested MVCS structure, but references some common code too, and some code from another product.
Is this something that would be supported by Cmd v3, and if so how, by analysing a directory structure, or a config file perhaps?

As I said, I do not use Architect (and am not about to start), but surely this layout should be supported?

Quote:

Originally Posted by westy

My application is properly laid out in the suggested MVCS structure, but references some common code too, and some code from another product.
Is this something that would be supported by Cmd v3, and if so how, by analysing a directory structure, or a config file perhaps?

Yes, the Cmd compiler can accept paths to folders on the command line (called the "classpath") and these can be configured if you use Cmd to generate a temporary app and copy its ".sencha" folder to your app.

Quote:

Originally Posted by westy

As I said, I do not use Architect (and am not about to start), but surely this layout should be supported?

Use of Sencha Architect is not required for Cmd. Cmd is a lower level tool but has similar conventions by default.

Cmd provides some high level commands that assume the app structure it generates but even that is not required to use the commands that accept paths. Also, many of the particulars of a generated app can be configured in the ".sencha/app/sencha.cfg" file or via Ant properties when using the generated build script.

Cool, so I should be aiming to generate an app, then check it's .sencha folder.
Sounds like once I have that sorted I can push that to the repo and we're good to go.

Thanks, will have another look when I get some time.