issue with multiple .next statements about curl

[unscriptable]

This may likely be a bug (need to verify), but there may be a better way to accomplish what you want to do. Have you tried using the !order suffix with the js! plugin?

    curl([ 'js!sharedJs/jquery.js!order', 'js!stepOne.js!order, 'js!stepTwo.js!order' ], function()
            {
                $(document).ready( function(){
                                                testOne();
                                                testTwo();
                                             });
            },
            function(){alert("something wrong")}
    );

Also: be careful about the all of the $(document).ready() calls. There's no guarantee what order these will fire in so they could be executing in the wrong order, which could cause the error you're seeing. I would remove the $(document).ready() calls within testOne.js and testTwo.js to be sure.

Regards,

-- John

[joopringelberg]

Thank you John. I was aware of order! However, it seems not applicable to my situation. I have a collection of apps that are organized in a family tree. Javascript modules are associated with the nodes, apps with leaves. An app requires all modules between the leaf where it sits and the root of the tree. Modules need be loaded in order (from root to leaf). E.g., the root may contain jquery while code at the other nodes depends on it. Sadly, none of my codefiles are written as modules - it is all plain old javascript. New code will be different, but that is how it is. Oh, and any of these modules will consist of multiple files - otherwise the whole problem would fold down to file ordering.
As I understood, order! affects the (plain javascript) files in a module - it cannot be used to order modules.

I've experimented with the order of the requirements in the module statement. I've tried to 'chain' the modules between leaf and root (make the root a requirement for level one nodes, level one nodes a requirement for level two and so on). However, in the end it doesn't give the right behaviour. I am beginning to realize that the A in AMD carries a lot of meaning ;-)

So that is why I tried .next - it seems perfectly fit for my purposes. I might try nesting curl statements (a curl statement in the callback of another) but I can well imagine the kind of problems that might run into.

But I will look into the $(document).ready() statements. I've used a lot of them. Maybe that's where the problem is.

As a question: can I rightly infer the order of loading that is picked by Curl from the order of script statements inserted? That is, the earlier scripts are at the bottom, last script is the top one?

[joopringelberg]

John,
I fixed the issue. It's all to do with closures ;-).

Line 705 of the curl.js in the src distribution runs:

        // promise chaining
        api['next'] = function (names, cb) {
            var origPromise = promise;
            promise = new Promise();
            // wait for the previous promise
            origPromise.then(
                // get dependencies and then resolve the current promise
                function () { ctx.require(names, promise, ctx); },
                // fail the current promise
                function (ex) { promise.reject(ex); }
            );
            // execute this callback after dependencies
            if (cb) {
                promise.then(function (deps) {
                    cb.apply(this, deps)
                });
            }
            return api;
        };

The nastiness is in the origPromise.then statement. The callback refers to location "promise". However, each following invocation of .next will modify the contents of that location. So we really need to preserve it and for this we need a closure:

        // promise chaining
        api['next'] = function (names, cb) {
            var origPromise = promise;
            promise = new Promise();
            // wait for the previous promise
            origPromise.then(
                // get dependencies and then resolve the current promise
                // Joop Ringelberg: Capture promise in a closure; we'll be modifying the content of this location on following .next statements!
                (function(p) {
                    return function () { ctx.require(names, p, ctx); }
                    }(promise)),
                // fail the current promise
                function (ex) { promise.reject(ex); }
            );
            // execute this callback after dependencies
            if (cb) {
                promise.then(function (deps) {
                    cb.apply(this, deps)
                });
            }
            return api;
        };

This solves the problem.

Regards,

Joop

[unscriptable]

Thanks or bringing this to my attention, Joop! I was studying ways to implement the missing closure you noted, and it helped me realize that the api code could be simplified! Creating some tests now to verify it's fixed.

Thank you!

-- John

[unscriptable]

Hello Joop,

Until we release 0.5.4, you can use the dev branch to take advantage of this fix.

Regards,

-- John

[joopringelberg]

Thanks John. It runs beautifully!
Joop

On 10/26/2011 07:09 AM, John Hann wrote:

Hello Joop,

Until we release 0.5.4, you can use the dev branch to take advantage of this fix.

Regards,

-- John