Opened 10 years ago

Closed 10 years ago

#8469 closed enhancement (fixed)

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

Reported by: spidey2099 Owned by: bill
Priority: high Milestone: 1.4
Component: Dijit Version: 1.2.3
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

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.

Attachments (2)

dojo-1.2-Test-1.1-BorderContainerContentPane.html (4.8 KB) - added by spidey2099 10 years ago.
dojo-1.1-Test-3-BorderContainerAccordionContainer.html (6.6 KB) - added by spidey2099 10 years ago.

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by spidey2099

comment:1 Changed 10 years ago by bill

Milestone: tbd1.3
Owner: set to bill
Status: newassigned

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

comment:2 Changed 10 years ago by bill

Description: modified (diff)

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...

comment:3 in reply to:  2 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by bill

Milestone: 1.3future
Summary: <someContainer>.resize() needs to be called for a layout to be rendered correctly.ContentPane: if adding layout widgets directly to ContentPane.domNode, need to call <someContainer>.resize()

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.

comment:5 in reply to:  4 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by 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.

comment:7 in reply to:  6 Changed 10 years ago by 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!!

comment:8 Changed 10 years ago by bill

Milestone: future1.4

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

comment:9 in reply to:  8 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by bill

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

comment:11 Changed 10 years ago by bill

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.