dojoInsertionIndex starts at 1 when it should start at 0 for child widgets of container widgets

[aaronmevans@…]

When using container widgets with child widgets defined in HTML markup, as the child widgets are created and registered with the parent, the "dojoInsertionIndex" is starting at 1 when it ought to start at 0.

What you end up with is this:

first child: at index 0 of the 'children' array but children[0].dojoInsertionIndex is 1 second child: at index 1 of the 'children' array but children[0].dojoInsertionIndex is 2

This is problematic because when you later try to add a child programatically using addChild(widgetRef), then you get:

third child: at index 1 of the 'children' array with a children[0].dojoInsertionIndex value of 2

It therefore bumps the widget that previously occupied children[1] to the end of the array creating a royal pain for widget developers.

When the third child is added programatically, there is a call to registerChild and the value of the insertionIndex argument is the size of the array (revision >= 4577, before that it was 0, which was even more problematic). This good because you would think then that the widget will end up as the last element in the array.

However, because of this code in registerChild and the fact that children created via markup start with a dojoInsertionIndex value of 1 rather than 0, it does not:

widget.dojoInsertionIndex = insertionIndex;

var idx = -1; for(var i=0; i<this.children.length; i++){

if (this.children[i].dojoInsertionIndex < insertionIndex){

idx = i;

}

}

this.children.splice(idx+1, 0, widget);

[bill]

This code has all been redone for 0.9.