Changes between Initial Version and Version 1 of Ticket #14946


Ignore:
Timestamp:
Mar 14, 2012, 12:47:32 PM (9 years ago)
Author:
bill
Comment:

Turns out it's a problem with the test case, or arguably a design problem in the spec of the placeAt() function. In other words, placeAt() is working according to spec, but the spec turns out to be confusing. I'm CC'ing Pete to see if he has anything to say, since placeAt() is his function.

The current rules are:

(1) if the reference widget has an addChild() method then pass it in without quotes. So, this works:

myWidget.placeAt(myLayoutWidget)

But this fails:

myWidget.placeAt("myLayoutWidget")

If placeAt() is passed a string, it's treated as a reference to a DOMNode, not as a reference to a widget.

(2) If the reference widget does not have an addChild() method, the opposite is true. This is correct:

myWidget.placeAt("myContentPane")

or slightly clearer:

myWidget.placeAt(myContentPane.domNode)

but this will fail:

myWidget.placeAt(myContentPane)

Of course, one way to avoid this problem is to stop using placeAt(). The test case could be rewritten to use addChild() for the layout widgets and set("content", ...) for the ContentPane.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #14946

    • Property Cc dante added
    • Property Summary changed from startup() called early doesn't layout correctly to placeAt() API confusing
  • Ticket #14946 – Description

    initial v1  
    11See attached file,   It doesn't layout correctly, although if startup() is called at the very end it does.
    2 
    3 May be an issue with a !StackContainer being created w/no children, or a !BorderContainer being created w/out a center pane.