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!

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:

Code:

app.classpath=${app.dir}/app

Try adding the library like so:

Code:

app.classpath=${app.dir}/app,lib/src

To share a library for all apps in a workspace, look in ".sencha/workspace/sencha.cfg". The "workspace.classpath" is empty by default, but you can add it there like so:

Code:

workspace.classpath=lib/src

Since Sencha Cmd is new, not all library sources written for previous releases of Ext JS will necessarily run in the new compiler. For example see this thread: http://www.sencha.com/forum/showthread.php?244218 where the issue was with how a class was declared using Ext.define.

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.

Code:

<!-- <x-compile> -->
<!-- <x-bootstrap> -->
<script src="ext/ext.js" type="text/javascript"></script>
<!-- This tag is only used in dev mode and is dropped by the compiler -->
<script src="lib/lib-all.js" type="text/javascript"></script>
<!-- </x-bootstrap> -->
<!--
The idea here is to tell the compiler that this script block defines all of the classes
used in "requires" or "extends" etc. to ensure that the compiler understands
This shim can be made into a JS file if needed on multiple pages
-->
<script type="text/javascript">
//@define Lib.foo.Bar
//@define Lib.foo.Thing
// Perhaps the lib does not declare its grid dependency:
//@require Ext.grid.Panel
// Now require the library (this should ensure the lib classes follow grid)
//@require lib/lib-all.js
</script>
<script src="app/app.js" type="text/javascript"></script>
<!-- </x-compile> -->

You will probably need to play with the library a bit to see what specific issues it might have, but the above should be a start.

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.

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.

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.

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.

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:

By doing that, the markup processor will inject a virtual requirement on the symbols file to the sch-all-debug file (it does this to preserve the script tag ordering during compilation). This way, since the symbols file comes first, it'll ensure that the requirements for sch-all-debug are met before it is loaded.

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.

my 404's

I added 8 or so Ext @require's to the externalized shim, and achieved a functioning build!

I also updated my index.html, per your example.
And, after moving sch-all-debug.js to a lib/, updated
paths appropriately and add the lib/ to my .cfg classpath.
Thank you for your advice and direction!

Building with Deft.js with Cmd v3

Really had a hard time getting my one and only Sencha Touch project to build with Deft.js using Cmd v3 - Started typing this whole thing out and found a solution toward the end. So I'll post it anyway. Seems relevant to this thread. Here goes:

First way I tried - Added deft.js to app.json, with no Deft references in app.js requires section.

Which I don't mind at all, because that's exactly the only way I could get things to build with the old sencha cmd.

This structure runs without building just fine. And it actually builds. But then I get a new kind of error - None of my view Controllers are found. It is like the new sencha command looked at them and said 'you'll not be needing these...' But the definitions are in the app.js.

I try flipping around things in the sencha.config file, thinking app is more important than Deft. No, thah dudun geddit.

If I add the view controllers to the controllers array, I get a Object [object Object] has no method 'getStores' error on load. So can't do it that way.

Solution was to add requires statements to all my views with view controllers, like so: