ContentPane: if adding layout widgets directly to ContentPane.domNode, need to call <someContainer>.resize()

[spidey2099]

As of the changes made to the content pane recently, a resize() needs to be explicitly called for a layout to render. Bug #8305 referes to this problem with the border container but it is true of all container's that have content pane's: BorderContainer, TabContainer and more recently, AccordionContainer.

There are also some more caveats - it appears that the attach (or wire-up) methodology for the tab and accordion containers has changed: it now requires a <someContainerWidget>.containerNode.appendChild (someDojoWidget.domNode). Without this tests indicate that the container and it's children don't fit precisely into their containing parent.

However - this being said. Once these new rules are adhered to, the AccordionContainer works well. It fits into it's containing parent and all the panes are rendered. So - many thanks for that.

[bill]

Hmm, you shouldn't need to call borderContainer.resize() after calling borderContainer.startup(). I'll try out your test case.

[bill]

Oh I see, thanks for the test case.

The issue here is probably that you are adding the top BorderContainer to an (already started) ContentPane. BorderContainer is expecting the ContentPane to call BorderContainer.startup(), and also BorderContainer.resize().

ContentPane._layoutChildren() calls resize() on each of it's children when the ContentPane is started but you are adding content after the ContentPane has started. I guess I could make ContentPane.addChild() call child.resize() in addition to child.startup(), although that wouldn't address the case if existing users are mucking with ContentPane.domNode and adding content directly.

Will think about it...

[spidey2099]

Replying to bill:

Oh I see, thanks for the test case.

The issue here is probably that you are adding the top BorderContainer to an (already started) ContentPane. BorderContainer is expecting the ContentPane to call BorderContainer.startup(), and also BorderContainer.resize().

ContentPane._layoutChildren() calls resize() on each of it's children when the ContentPane is started but you are adding content after the ContentPane has started. I guess I could make ContentPane.addChild() call child.resize() in addition to child.startup(), although that wouldn't address the case if existing users are mucking with ContentPane.domNode and adding content directly.

Will think about it...

Your explanation helps clarify some of my confusion on the content pane's new resize() functionality. It is a tricky thing. BTW - I do like the content pane's changes and the resize() strategy makes a lot of sense. I will check for a fix as and when it happens. Thanks for looking into it.

[bill]

OK, glad I could clarify. I've been thinking about this issue and I haven't been able to think of any good way to handle it.

We might have to tell people that if they are mucking directly with the ContentPane's contents (accessing ContentPane.domNode), rather than setting the contents through an href or attr('content', ...) or initially in markup, that they need to call resize() on each child widget.

Could of course add a utility function to ContentPane to do this but not sure if it's worth it.

[spidey2099]

Replying to bill:

OK, glad I could clarify. I've been thinking about this issue and I haven't been able to think of any good way to handle it.

We might have to tell people that if they are mucking directly with the ContentPane's contents (accessing ContentPane.domNode), rather than setting the contents through an href or attr('content', ...) or initially in markup, that they need to call resize() on each child widget.

Could of course add a utility function to ContentPane to do this but not sure if it's worth it.

Also found out that with the new methodology resizing does not take place. If a tab or accordion is placed in any pane that resizes, the tab and accordion will retain the size that they had when first associated with the pane. The question is: can we put something in there that allows the tab and accordion to resize when their containing parent resizes. Thanks.

[bill]

Resizing works in general; there's a bunch of code in ContentPane starting with _checkIfSingleChild(). Probably it's not working in your case because you are setting ContentPane.domNode directly.

I guess I could change the code to call _checkIfSingleChild() more often, on every resize() call, but that's more of an enhancement.

[spidey2099]

Replying to bill:

Resizing works in general; there's a bunch of code in ContentPane starting with _checkIfSingleChild(). Probably it's not working in your case because you are setting ContentPane.domNode directly.

I guess I could change the code to call _checkIfSingleChild() more often, on every resize() call, but that's more of an enhancement.

Agreed - it is an enhancement - but if we could do that, and the resizing would take place, it would be really cool. I know it would make my day!!

[bill]

OK, marking as 1.4 for the change to call _checkIfSingleChild() from ContentPane.resize().

[rct]

For what it's worth, The dijit test ​test_BorderContainer_prog.html included with the distribution shows this behavior on the left pane that is added programmatically. You can't move the left spiltter without a resize occuring.

To reproduce:

1. load ​test_BorderContainer_prog.html
2. Click "add left pane" button.
3. Try to move the left splitter, note that you can't.
4. resize the browser.
5. now you can move the left splitter.

Note, you see the same behavior, even if you click the button to remove the top pane (removeChild()). The borderContainer has been repainted, but the left splitter still is immobile until a browser resize.

[bill]

I think that's a different bug, I filed it under #9881.

[bill]

(In [20091]) Call _checkIfSingleChild() on every resize() call, in case the contents have been changed manually. Fixes #8469 !strict.