_Templated: some nested widgets in template no longer get startup() called

[dstarke]

Commit [19488] changed the way that the _Templated class records its supporting widgets.

Since this change, I find that when I have a template that defines widgets with nested widgets inside, the inner widgets are not getting startup() called on them. For layout reasons, the inner widgets are sometimes not direct children of the widget's DOM node-- my understanding is that this should be allowed.

Researching further, I find that the _supportingWidgets array is empty even though there should be a number of widgets there. It turns out that when my template is initialized, dijit.findWidgets(), which is what is now used to populate _supportingWidgets, is returning an empty list. My understanding is that findWidgets only finds the widgets that are direct children, but in this case, there are none, or some are missing.

There does not appear to be any other mechanism to cause these inner widgets to get started up.

Reverting the portion of change 19488 that assigns the contents of _supportingWidgets (to make it the output of parse()) resolves this problem.

[bill]

Hmm, that's not good. Can you attach a test case?

Maybe _Templated needs to do call startup on the nested widgets that don't have a _Container as a parent, not just top level widgets, like the parser does at the page level:

d.forEach(thelist, function(instance){
	if(	!args.noStart && instance  && 
		instance.startup &&
		!instance._started && 
		(!instance.getParent || !instance.getParent())
	){
		instance.startup();
	}
});

[bill]

Nathan is going to write some tests for this and then we'll fix the code.

[Nathan Toone]

(In [19799]) Refs #9657 - add test case for making sure that child widgets are correctly started up

[Nathan Toone]

(In [19800]) Refs #9657 - roll back change 19488 - which breaks startup of nested widgets, as shown by new test case _Templated-widgetsInTemplate.html

[Nathan Toone]

(In [19801]) Fixes #9657 - fix issues with destroy getting called multiple times. This should address #9657

[Nathan Toone]

(In [19802]) Refs #9657 - inherited needs to be called before the resizing - since that is where we moved the startup calls to

[bill]

I'm pretty sure that after the above changes (which do fix the startup() problem), destroyRecursive() will be called twice on children of widgets that don't define isContainer:true (ie, widgets that don't extend ContentPane or_Container). For example, if foo is a simple widget not extending _Container:

dojo.declare("foo", [dijit._Widget, dijit._Templated], {
    templateString: "<div dojoType=containerNode></div>"
});

Then if we have a widget that references "foo" in it's template:

<div>
   <div dojoType=foo>
        <div dojoType=bar></div>
   </div>
</div>

The children of "foo" ("bar" in the above example) will be destroyed twice.

Admittedly that's an unusual case but it should be addressed; destroyRecursive() should really only be called on the top level widgets (foo in the example above).

Talked w/Nathan about this but reopening ticket so we don't forget.

[Nathan Toone]

(In [19904]) Fixes #9657 - fix typo in test case - which then failed - and then fix the failure !strict

[Nathan Toone]

(In [19905]) Fixes #9657 - if at first you don't succeed....there's got to be a better way of doing this. :)

[bill]

(In [19928]) Widgets that have children must define containerNode (regardless of widgetsInTemplate). Otherwise getChildren(), destroyDescendants() etc. don't work.

So, updating the test by removing that case, and then simplifying the code to compute _supportingWidgets so it only has top level supporting widgets.

Refs #9657 !strict.