BorderContainer is setting a region for *all* children - even if they don't have a region.

[nathan]

Since the default region is set to "none", the code that sets the region for subwidgets of a BorderContainer? is getting set when it shouldn't be.

A patch follows.

[guest]

Patch to only apply positioning if a subwidget has a region set.

[Adam Peller]

I didn't intend to support this, but I see the default setting of 'none' which must have gotten copied over from the old LayoutContainer?. Is this useful? What's the expected behavior?

[guest]

It actually is useful - especially when trying to convert legacy code (which used LayoutContainer?).

The expected behavior (at least for me) is to leave "non-regioned" widgets as-is - and they appear in the normal flow of the page. Their position is not changed to "absolute" (like it is for regioned widgets).

[bill]

Hi Nathan. I think what Adam actually meant was "why is this useful?" (or "how is this useful?"). I understand what feature you want but I don't see the benefit to it. (Although it is trivial to allow.)

[guest]

I guess that the biggest reason it is useful is that I don't expect a region to be applied if I'm not setting a region. (It's more of an expectation thing). I currently am using it when I want one widget positioned - but the remaining widgets not to be positioned. It also appears that issues happen when more than one widget is positioned in the same region (as happens when you don't explicitly set the region).

One could nest widgets within a ContentPane? that has region set to center - it just seems like an odd way to work around it...from someone who is developing an application, it just makes sense to not "pseudo-position" an element that hasn't been explicitly positioned.

The other issue that is encountered is having a widget with region="none", its position style attribute gets set to "absolute" - however, it never gets "positioned" (in _layoutChildren)....meaning that any widgets with region none set end up getting stacked on top of each other.

Again - it's mainly just an expectation thing...it seems to "behave" better (and, in my opinion, is better practice) not to touch the style of a widget that isn't explicitly positioned...I'm mainly talking about the "absolute" position that is applied (and the css class) in _setupChild... And like I said, it's "work-around-able" - just not (at least to me) in a very logical manner.

[guest]

Bill asked for an example of when you might want to use something like this - I have uploaded one to ​http://www.toonetown.com/example/index.html

That example is based off of 1.0.2 - and uses LayoutContainers? instead of BorderContainers?...but the idea behind it is the same.

[bill]

OK, talked this over with peller and nathan. The "default" region is now "", implying, effectively, that there is no default and thus that the user needs to set some value for it (center, left, right, etc). In the example above it's better to just use a custom widget that mixins in _Contained in order to be able to use getSiblings(), rather than to have a BorderContainer? widget that isn't actually doing any layout.

[Adam Peller]

(In [12446]) apparently, I forgot to check this in. be tolerant of missing 'region' attribute (bug or feature?) Fixes #5797 !strict