Sencha SDK Tools 2.0 and ExtJS4: The Missing Docs

[papaja]

I'm trying to follow your instruction and I've put ext-dev.js instead of ext-debug.js.

I get these errors:
$ sencha create jsb -a index-build.html -p app.jsb3 -v
[E] Failed loading 'src/app/Application.js', please verify that the file exists
[object Object]
Failed loading 'src/app/Application.js', please verify that the file exists
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 8712
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 8216
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 2454
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 7943
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 7892

This happens with original and with your phantom file so this is caused by ext-dev. Any idea why?

If I use ext-debug I don't see these errors.

[Sottilde]

I'm trying to follow your instruction and I've put ext-dev.js instead of ext-debug.js.

I get these errors:
$ sencha create jsb -a index-build.html -p app.jsb3 -v
[E] Failed loading 'src/app/Application.js', please verify that the file exists
[object Object]
Failed loading 'src/app/Application.js', please verify that the file exists
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 8712
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 8216
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 2454
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 7943
file:////media/Podaci/web/ks/lib/ext-4.0/ext-dev.js : 7892

This happens with original and with your phantom file so this is caused by ext-dev. Any idea why?

If I use ext-debug I don't see these errors.

Okay. This may have something to do with your Ext.Loader configuration. I would assume that if you open up that same index-build.html in your browser and view the console, you would get the same error, no?

I don't know if you're using Architect or not but your Ext.Loader config in app.js should look something like this:

Ext.Loader.setConfig({
    enabled: true,
    paths: {
        Ext: './lib/extjs/src',
        MyApp: './app
    }
});

Also, does your index-build.html include your app.js?

[abcoa]

Sottilde
First of all - great document...I really had tough time getting my Sencha Architect project working with my MS Visual Studio (it was all manual)

One question though...
How did you resolve managing dependencies that are not on the main application Viewport?

Let me elaborate...
I for example have a grid that only shows after clicking on the menu item after inital page loads in...Create JSB process picked up a grid component dependency somehow but missed grid columns (Number, etc, etc...)

Have you run into this? If so how did you solve it?

Only thing I can think of is to keep adding JS references to individual files to index-build.html...but that is going to get old pretty soon....

Interesting. I too have a number of dependencies similar to this but they all loaded correctly. I have a viewport that contains header, content, and footer containers. The content container is the real meat of the application, and it is simply a card layout. When I recently added a grid to my app the dependencies were added, but some of them appear to be resolved AFTER Ext.onLoad, which is why I added the 5000ms setTimeout to phantom-jsb.js.

You may be able to help your issue by adding requires[] or uses[] statements to files that are loaded before Ext.onReady. I solved some issues I had with History and Cookies modules by simply including a file that contains these requires statements, before I include app.js. You may have luck with this. If you simply require your app's views that are not being loaded properly, it should also load all its dependencies.

I suppose the only "correct" solution to this issue in the future may be for phantom-jsb.js to run a test case that runs though the app, then to grab the contents of Ext.Loader. But there are of course authentication and other issues with that. Otherwise, you may be stuck including just ext-all.js and your application files in the .jsb3, and letting JSBuilder minify that. But I suppose that's nothing more than you could get with any simple minification tool.

I have noticed several things (using ext-debug.js):
When I load my app via browser and initial viewport loads, a number of dependencies are loaded.
But then, when I navigate to a different view (in my case a new tab in central tabpanel is opened that has a grid) a slew of other dependencies are being loaded on demand. But I think this goes to tell that if phantomJS is looking up Loader.history to figure out dependencies and you provide only initial view then it will not know about other ones (it cannot navigate to this other view magically).
The solutions are (as you indicated)
- to either provide all these dependencies in index-build.html
- use requires statements (ughhh...)

Neither, in my opinion is maintainable

Then I started thinking about what you said regarding including ext-all.js...
For a fairly complex app, why not just combine app's code with it and minify everything.
If you can say that app is using 75% of the framework and you decide to include ext-all.js, you would be making a trade-off between headeaches of dependency management and having few extra bytes being downloaded by clients (I have not checked, but I think extra 25% of framework your app is not using would not add a lot of overhead)

I am really considering this approach, but there is now another culprit....
How do I generate JSB3 file with a target that has only my apps files (and none of ext js ones)....
If I can do this in some automated fasion that would be great....
Can phantom js task that reads Ext.Loader.history generate 2 targets by filtering Ext dependencies and your Apps dependencies (I think it could becuase you have to give your app the namespace)


Saga continues...

[Sottilde]

Can phantom js task that reads Ext.Loader.history generate 2 targets by filtering Ext dependencies and your Apps dependencies (I think it could becuase you have to give your app the namespace)

Simply include ext-all-dev.js in your index-build.html, instead of ext-dev. This will cause Ext.Loader to not load any Ext dependencies, and thus they will not end up in your jsb3.

[Guyalain]

hello
i would like to test the Ext JS.

thank´s a lot
Guy

[papaja]

Thanks, after I've set path to Ext it does not generate error.

[papaja]

Simply include ext-all-dev.js in your index-build.html, instead of ext-dev. This will cause Ext.Loader to not load any Ext dependencies, and thus they will not end up in your jsb3.

Because I belong to this group which has dependencies loading after click I followed this advice with one of including ext-all.js in build target for app-all.js, and I got millions of errors like:

[ERROR] 18:1137:illegal character

[ERROR] 18:1137yntax error

[ERROR] 18:1229:illegal character

[ERROR] 18:1229yntax error

[ERROR] 18:1455:illegal character

[ERROR] 18:1455yntax error

[ERROR] 18:1463:illegal character

[ERROR] 18:1464:illegal character

[ERROR] 18:1464yntax error

[ERROR] 18:1518:illegal character

...
[ERROR] 147:8192:unterminated string literal

[ERROR] 148:2yntax error

[ERROR] 148:175:missing } after property list

[ERROR] 148:335yntax error

[ERROR] 148:417:invalid return

[ERROR] 148:463:missing ; before statement

[ERROR] 148:627:invalid return

[ERROR] 148:665:missing ; before statement

[ERROR] 693:0:missing } in compound statement

[ERROR] 693:0:missing } in compound statement


[ERROR] 1:0:Compilation produced 515 syntax errors.

org.mozilla.javascript.EvaluatorException: Compilation produced 515 syntax errors.

at com.yahoo.platform.yui.compressor.YUICompressor$1.runtimeError(YUICompressor.java:135)

at org.mozilla.javascript.Parser.parse(Parser.java:410)

at org.mozilla.javascript.Parser.parse(Parser.java:355)

at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:312)

at com.yahoo.platform.yui.compressor.JavaScriptCompressor.<init>(JavaScriptCompressor.java:533)

at com.yahoo.platform.yui.compressor.YUICompressor.main(YUICompressor.java:112)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:616)

at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:20)

Loading the Project Name Project
Loaded 0 Packages
Loaded 2 Builds

Creating the "All Classes" target as "all-classes.js"
- 10 file(s) included in this target.
+ app/view/appmenu/Menu.js
+ app/view/invoice/List.js
+ app/view/report/Daily.js
+ app/model/Invoice.js
+ app/store/Invoices.js
+ app/model/Partner.js
+ app/controller/Menu.js
+ app/controller/DailyReport.js
+ app/store/Partners.js
+ app/controller/Invoice.js
* Parse all-classes.js with options:
- debug: true
- debugLevel: 1

Creating the "Application - Production" target as "app-all.js"
- 3 file(s) included in this target.
+ lib/ext-4.0/ext-all.js
+ build/all-classes.js
+ app.js
* Parse app-all.js with options:
- debug: false
- debugLevel: 1
* Compress and obfuscate app-all.js...

Copy resources...

Done building!



Any idea why?

[Sottilde]

Ah yes, I had forgotten, ext-all.js is compressed in a such a severe way that it causes compilation issues when you attempt to re-compress it.

The best way to go may be to compress your app files into a compressed all-classes.js, but to set compress to "false" when creating app-all.js. I am not certain this would be successful but I believe it would simply concatenate all-classes.js and ext-all.js to app-all.js, instead of trying to compress them in.

[papaja]

For now I exclude ext completely from app.jsb3 and add it as separate js resource in my html file.

[Sottilde]

For now I exclude ext completely from app.jsb3 and add it as separate js resource in my html file.

That should work fine. For anyone who is reading, if you simply include ext-all.js in a separate final build target that does not minify, you will not get the above errors and still maintain a monolithic build file.