asyncparser.js

// untested poc/theory code
define(["dojo/parser"], function(parser){

    var asyncParser = function(rootNode, oldSupport){
        // summary: An asyncronous 
    
        var dfd = new dojo.Deferred(),
            deps = dojo.query("[dojoType], [data-dojo-type]", rootNode).filter(function(n){
                return (n.getAttribute("data-dojo-type") || n.getAttribute("dojoType")).replace(/\./g, "/");
            })
        ;
        
        deps.push("dojo/ready!");
        require(deps, function(){
            dfd.callback(parser.parse(rootNode))
        });
        
        return dfd;
    }

    return asyncParser;

});

// usage:
define(["dojo/asyncparser"], function(parse){
    dojo.when(parse(), function(){
        alert("all widgets insantiated");
    })
})

i'm fairly certain that the dojo/ready! dep shouldn't be needed. thinking about it, all the deps will be loaded by the time you call the parser and that's all you should need to be waiting on. something external to this needs to make sure that the dom is ready since you're doing the dojo.query to get the deps list to begin with. afaik, those are the only 2 things that dojo/ready! provides so in this case it shouldn't be needed.

ahh makes sense. I'm just in the habit of

{{{
dojo.require("a.b.c");
dojo.ready(theyAReDone)
}}}

and that translated into my deps pushing

... either way, I've not actually run/tested this snipplette of code, it was the result of thread on dojo-contrib and me seeing how it might work out.

not sure how to handle the "we don't use globals" vs "well where do you put it" question just yet.

it looks like a reasonable poc for how i'd imagine it might work.