#5797 closed defect (fixed)
BorderContainer is setting a region for *all* children - even if they don't have a region.
Reported by: | nathan | Owned by: | Adam Peller |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Dijit | Version: | 1.0 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
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.
Attachments (1)
Change History (10)
Changed 13 years ago by
Attachment: | bordercontainer.diff added |
---|
comment:1 Changed 13 years ago by
Cc: | [email protected]… removed |
---|---|
Component: | General → Dijit |
Milestone: | → 1.1 |
Owner: | changed from anonymous to Adam Peller |
Reporter: | changed from guest to [email protected]… |
comment:2 Changed 13 years ago by
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?
comment:3 Changed 13 years ago by
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).
comment:4 Changed 13 years ago by
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.)
comment:5 Changed 13 years ago by
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.
comment:6 Changed 13 years ago by
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.
comment:7 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
comment:8 Changed 13 years ago by
comment:9 Changed 13 years ago by
Reporter: | changed from [email protected]… to nathan |
---|
Patch to only apply positioning if a subwidget has a region set.