Success! Looks like we've fixed this one. According to our records the fix was applied for SDKTOOLS-187 in a recent build.
  1. #1
    Sencha Premium Member
    Join Date
    Jun 2012
    Location
    Boston, MA
    Posts
    44
    Vote Rating
    3
    chrisfarrell is on a distinguished road

      0  

    Default Does Cmd v3 support vendor libraries?

    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!

  2. #2
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Location
    Kansas
    Posts
    1,513
    Vote Rating
    176
    dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of dongryphon has much to be proud of

      1  

    Default


    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.

    Which specific ux components or libraries do you have in mind?
    Don Griffin
    Engineering Manager - Frameworks (Ext JS / Sencha Touch)

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  3. #3
    Sencha Premium Member
    Join Date
    Jun 2012
    Location
    Boston, MA
    Posts
    44
    Vote Rating
    3
    chrisfarrell is on a distinguished road

      0  

    Default Thank you!

    Thank you!


    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:

    /path/to/workspace/myApp/app/app.js
    /path/to/workspace/myApp/app/sch-all-debug.js

    So, I am assuming that this classpath in sencha.cfg includes the vendor lib:
    app.classpath=${app.dir}/app

    And, my index.html looks like this:

    Code:
    <!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>
                <script src="app/sch-all-debug.js"></script>
            <!-- </x-bootstrap> -->
    
    
            <script type="text/javascript">
                //require the lib definitions
                //@define Sch.panel.SchedulerTree
                //@define Sch.model.Resource
                //@define Sch.data.ResourceTreeStore
                //@define Sch.model.Event
                //@define Sch.data.EventStore
    
    
                //require the library
                //@require app/sch-all-debug.js
            </script>
    
    
            <script src="app/app.js"></script>
    
    
        <!-- </x-compile> -->
    </head>
    <body></body>
    </html>
    Is there another setting I need to add?

  4. #4
    Sencha Premium Member
    Join Date
    Jun 2012
    Location
    Boston, MA
    Posts
    44
    Vote Rating
    3
    chrisfarrell is on a distinguished road

      0  

    Default upgrade Bryntum license

    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.

  5. #5
    Sencha - Ext JS Dev Team
    Join Date
    Jan 2012
    Posts
    41
    Vote Rating
    10
    kkrohe will become famous soon enough

      0  

    Default


    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.

  6. #6
    Sencha Premium Member
    Join Date
    Jun 2012
    Location
    Boston, MA
    Posts
    44
    Vote Rating
    3
    chrisfarrell is on a distinguished road

      0  

    Default externalizing the symbols

    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.

  7. #7
    Sencha - Ext JS Dev Team
    Join Date
    Jan 2012
    Posts
    41
    Vote Rating
    10
    kkrohe will become famous soon enough

      0  

    Default


    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.

  8. #8
    Sencha - Ext JS Dev Team
    Join Date
    Jan 2012
    Posts
    41
    Vote Rating
    10
    kkrohe will become famous soon enough

      0  

    Default


    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:

    Code:
    <!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>
    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.

    (Updated to add the index.html alternative)

  9. #9
    Sencha Premium Member
    Join Date
    Jun 2012
    Location
    Boston, MA
    Posts
    44
    Vote Rating
    3
    chrisfarrell is on a distinguished road

      0  

    Default my 404's

    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!


    Last edited by chrisfarrell; 3 Oct 2012 at 4:36 PM. Reason: updated to reflect successful workaround

  10. #10
    Sencha User
    Join Date
    Jun 2012
    Posts
    7
    Vote Rating
    0
    edhubbell is on a distinguished road

      0  

    Default Building with Deft.js with Cmd v3

    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.


    Runs fine without build. When built using sencha command 3, like so:
    sencha ant -d -p skip.sass:1 package build


    I get a 'failed to resolve dependency Deft.mvc.ViewController for file MyApp.controller.LoginViewController'. So I can't build.


    (my old build command with the old sencha command, was sencha app build package -d myAppComPackage/public, fyr)


    So I change /.sencha/app/sencha.cfg, adding deft:
    app.classpath=${app.dir}/Deft,${app.dir}/app.js,${app.dir}/app


    And take Deft.js out of the app.json file, and copy Deft's .js files into a Deft folder in my app.dir, and decide to load everything up in the requires section of app.js, thusly:


    Code:
        requires: [
            'Ext.MessageBox'
            ,'Ext.TitleBar'
            ,'Ext.Img'
            ,'Ext.data.proxy.JsonP'
            ,'Ext.DateExtras'
            ,'Ext.Label'
            ,'Ext.ux.LeafletWrapper'
            ,'Ext.ux.slidenavigation.View'
            ,'Deft.core.Class'
            ,'Deft.event.LiveEventBus'
            ,'Deft.event.LiveEventListener'
            ,'Deft.ioc.DependencyProvider'
    etc...
    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:


    Code:
        alias: 'widget.trucklistview',
        controller: 'myApp.controller.TruckListViewController',
        requires: ['myApp.controller.TruckListViewController'],
    Which I have to guess lets sencha cmd 3 know that we're going to need those view controllers when the views are built, so get stuff in the right order.

    Now I can build in RC2 with Cmd v3, and everything appears to be fine. Hope this helps someone.
    ~Ed

Thread Participants: 3

Tags for this Thread