dojox.layout.ContentPane / dojo.html._ContentSetter parse fails when modules loaded async (AMD)

[James Burke]

This was brought up on dojo-interest. If dojox.layout.ContentPane? is used in an xdomain environment, and the loaded content for the ContentPane? has dojo.require() for some widget and parsing of widgets turned on, then since xdomain loading is an async process, the widget parsing in the content for the ContentPane? could fail.

I think putting a dojo.addOnLoad wrapper around the interior actions of dojo.html._ContentSetter._parse should fix the problem, but I am not sure of the general impact on the expectations of _ContentSetter -- do people assume that when the onLoad fires for the content that widgets are always parsed and ready? Does the onLoad need to be fired after the possibly async dojo.addOnLoad block fires?

[Sam Foster]

[CLA] dojox.layout.ContentPane? subclass + demo page that finds and requires dojoType dependencies (same/cross-domain)

[Sam Foster]

the load/setting sequence in dojox.layout.ContentPane? is indeed problematic. I recently worked on a proof-of-concept subclass that dojo.requires dependencies in the content (not tackling the module : class mapping issue). I've attached it as prerequires.zip. It's not ready to be a patch - it only handles string content, and there are a load of other param permutations I've not tested, but its worked through the addOnLoad idea.

/Sam

[Mike Wilcox]

(In [19921]) Refs #9695, #9578, #9615 - Fixed memory leak. Fixed HTML single upoad destroying fileInput. Fixed IE invalid argument.

[bill]

Kitsonk is looking at addressing this problem as part of the patch for #14591 (although I wouldn't call this a duplicate ticket).

[Kitson Kelly]

Fixes async setter, but requires parser to return Deferred

[Kitson Kelly]

Correct, I have attached just the html.js patch to the ticket, but it will not work properly until the parser returns a Deferred as part of the parse (although I could rewrite it to do a Deferred.when, instead, but I don't think it will fully address the issue here unless the parser changes as well).

I wouldn't say it is a duplicate either, but more of having to address this issue manifesting itself with changing the parser to auto-require and therefore causing the same issue to manifest itself in a different way.

[bill]

#14932 is a duplicate of this ticket.

[bill]

The declarative require feature is being tracked in #15118, but I think we should probably support the old syntax of loading an href like:

<script>
    dojo.require("dijit/Menu");
</script>
<div data-dojo-type="dijit.Menu">...</div>

So I'll work on that.

[bill]

In [28278]:

Fix dojox.layout.ContentPane.executeScripts for scripts with require() or dojo.require(), and async:true.

Fixes #9578 !strict.

[André Ribeiro de Miranda]

resize parent

// Call onEnd() in the superclass, for parsing, but only after any require() calls from above executeScripts 
// code block have executed.  If there were no require() calls the superclass call will execute immediately. 
var superClassOnEndMethod = this.getInherited(arguments), 
    args = arguments,
    parents = []; 
dojo.ready(lang.hitch(this, function() {
    superClassOnEndMethod.apply(this, args);
                                
    dojo.forEach(this.parseResults, function(widget) {
        var validParent,
            parent;
        validParent = widget.getParent();
        while (validParent) {
            parent = validParent;
            validParent = parent.getParent();
        }
        if (parent && dojo.indexOf(parents, parent) == -1) {
            parents.push(parent);
        }
    });
    dojo.forEach(this.parseResults, function(widget) {
        if (typeof widget.startup != 'undefined') {
            widget.startup();
        }
    });
    dojo.forEach(parents, function(widget) {
        widget.resize();
    });
}));