28 Sep 2012 1:41 PM #1
Does Cmd v3 support vendor libraries?
Trying to find the right question for my problem.
I can not figure out how to build an app with definitions (models, views, stores, controllers) that extend 3rd party/vendor library definitions. In my particular case, the vendor lib definitions are themselves extensions of Ext definitions.
I've added the vendor lib to my app.json's "js" paths, and have added the lib in my index.html.
And, the app runs, uncompiled, without error.
Does the Cmd v3 tool support compiling apps that use vendor libs like this?
If so, how? If not, is there a roadmap for support? And, what should I do in the mean-time?
Thank you for any hints whatsoever!
29 Sep 2012 12:04 AM #2
The ideal way to use 3rd party Ext JS code is to include their "src" root in your classpath.
For a simple app, look in ".sencha/app/sencha.cfg". This is the default:
We may need some tweaks to better integrate 3rd party Ext JS libraries that do not yet compile with Sencha Cmd, but one possibility for the moment is to create a shim like the one below.
Which specific ux components or libraries do you have in mind?
1 Oct 2012 9:32 AM #3
I am trying to build with the Bryntum Scheduler.
The shim seems to be working - up to a point.
All of the dependency issues are gone - which is great.
Now, I run into the following error:
Error executing page compilation Failed loading source file: /path/to/workspace/myApp/sencha-compile-temp-dir/6b1bb366-4b9b-4475-ae07-15f337614347/app/sch-all-debug.js
My vendor lib source file is sibling to my app.js:
So, I am assuming that this classpath in sencha.cfg includes the vendor lib:
And, my index.html looks like this:
2 Oct 2012 9:30 AM #4
upgrade Bryntum license
Looks like the solution is to upgrade from free trial of Bryntum license.
Upgrading will, allegedly, enable me to ditch the @define and @require directives and
simply use the sencha.cfg classpath - which is how it's suposed to work.
We'll see! I will be acquiring a commercial license soon and will report back.
2 Oct 2012 10:45 AM #5
Looks like an issue in the markup processing pass.
Internally, the markup processor will extract inline source blocks contained in <x-compile> sections into their own source files in the sencha-compile-temp-dir staging directory. The problem here is when an @require tag to a file path is used withing one of those inline script blocks.
Requirements specified with relative paths like that are resolved based on the relative path from the js file in which the requirement was found. In this case, the relative path is being calculated from the temp file we generated for the script block, which is incorrect.
Here, the relative path should be calculated from the index.html page that contained the script block, so we'll need to fix that. I've pushed this thread to the bug tracker accordingly.
As a work around, you should be able to create a file next to app.js and sch-all-debug.js (something like sch-symbols.js), and place the contents of that script block in that file, updating the last @require to simply sch-all-debug.js as part of that as well. Then, in app.js, add a //@require sch-symbols.js at the top.
This should cause all the necessary metadata to be found by the compiler during normal class path scans, so the relative paths to things should be calculated correctly in this case.
One other note: Since you're needing to supply all the symbol data here for the scheduler, you might also need to add some require tags for framework files that are needed by the scheduler into the sch-symbols data, since the compiler will see that symbol data as not having any requirements on the framework, it might sort those files above the framework during load order processing. However, as you say, if the license upgrade gets you access to the sources, then simply having those on the class path should work as intended.
2 Oct 2012 12:09 PM #6
externalizing the symbols
Thank you. Externalizing the symbols got me past the 'Failed to load error', and the build process completed without error.
However, now, when I try to run the built index.html, loading all-classes.js, I get about 150 404's.
The topmost error in my console is:
Uncaught TypeError: Cannot read property 'Connection' of undefined
Is this the symptom for needing to add //@require Ext.package.Class to my sch-symbols.js?
I've tried a couple things:
1. I added a bunch //@require Ext.some.Class to the top of sch-symbols,js. This did not reduce my 404's. The classes I added were still 404 not found.
2. I added ext-all.js to my built index.html. This eliminates the Uncaught TypeError, but not any of the 404's.
It may be a few days before I get access to the Bryntum src, so getting a workaround functioning would be wonderful. Thank you for any further advise.
2 Oct 2012 12:30 PM #7
Yeah, that's what I was suspecting might happen and is the reason for needing the extra require tags in sch-symbols.
It would help if you could post the resources that are generating the 404 errors so I can verify what it's trying to look up, but I suspect that adding the require tags will be the resolution, but the trick might be finding the correct ones.
One thing you can do is to run the sencha command with the -debug flag. As part of the debug output, there will be a block of debug message that look like "writing file ..." as it concatenates the various files into the all-classes file. That should help determine the order that the compiler is producing during the dependency scan.
My guess is that the sch-* files will be showing up very early, shortly after the core ext files, but before most of the Ext ui classes. What you might end up needing to do is cross reference the 404 errors with the load order being generated, and add require tags for the missing classes that show up latest in the load order, as well as any files that don't show up in the concatenation pass at all. That should cause the scheduler symbol files to move down in the load order to the appropriate point, and the debug output should reflect that change.
2 Oct 2012 12:37 PM #8
Another possible issue could be that the compiler is sorting the sch-all-debug.js file very early, but is sorting the sch-symbols file correctly (the debug output will show this happening if this is the problem).
If that's the case, then you'll need to control the load order of that file specifically, and there are a couple of ways to achieve that. The best would be to remove the require tag for the symbols file in app.js, remove the require tag for sch-all-debug in the symbols file, and update index.html accordingly:
<!DOCTYPE HTML> <html> <head> <meta charset="UTF-8"> <title>MyApp</title> <!-- <x-compile> --> <!-- <x-bootstrap> --> <script src="../ext/ext-all-dev.js"></script> <script src="bootstrap.js"></script> <!-- </x-bootstrap> --> <script src="app/sch-symbols.js"></script> <script src="app/sch-all-debug.js"></script> <script src="app/app.js"></script> <!-- </x-compile> --> </head> <body></body> </html>
Another option is to add the metdata directives from the symbols file directly into the sch-all-debug file. Since this metadata is all comment based, it shouldn't impact run-time behaviors, just add the necessary metadata. This option is less ideal, though, as you'd have to modify external files at that point, which would make upgrading more challenging at least.
(Updated to add the index.html alternative)