8 May 2012 11:13 PM #1
Nested Containers with RadioButtons break layout
Nested Containers with RadioButtons break layout
VerticalLayoutContainer v = new VerticalLayoutContainer();
HorizontalLayoutContainer h = new HorizontalLayoutContainer();
v.add(new FieldLabel(new TextField(), "Field"));
Radio r1 = new Radio();
Radio r2 = new Radio();
The border of the vertical layout container contains the RadioButtons.
The RadioButtons are drawn outside the VerticalLayoutContainer:
Bildschirmfoto 2012-05-09 um 09.09.29.png
9 May 2012 3:39 PM #2
VerticalLayoutContainer and HorizontalLayoutContainer are containers that expect to be sized either explicitly or by their parent containers. They are not meant to be sized by their contents.
In your example, you're relying on the size of the two Radios to give the HorizontalLayoutContainer its size. This won't work. You can work around this by giving the HorizontalLayoutContainer an explicit height. However, in your example, you probably want to use CssFloatLayoutContainer instead. This is a container that uses floats instead of absolute positioning to position its children. This allows the container to take up as much space as the children need.
It's hard to tell without more context whether you intend to put the VerticalLayoutContainer in another component that does give it an explicit size. If you do not, consider another container instead, such as FlowLayoutContainer.
9 May 2012 3:41 PM #3
I've moved this thread to the GXT Discussion forum as it doesn't describe a GXT bug.
9 May 2012 11:21 PM #4
9 May 2012 11:39 PM #5
10 May 2012 5:58 AM #6
I'd love to hear more about each separate container, what its use cases are, and what to expect from them. This kind of documentation is vital to making sure threads like this one don't pop up every now and then, IMHO.
That's vital information for us to know what containers to use for a certain layout we have in mind.
As for me, currently, it's more trial and (too much) error.
VerticalLayoutContainer and HorizontalLayoutContainer are not meant to be sized by their contents.
10 May 2012 9:43 AM #7
The purpose of most html/css styles and settings is to allow children to size parents. This creates the page effect that we are used to in articles, blogs, forums, where to view more content, you must scroll down the page further.
In contrast, most applications work by allocating a fixed amount of space (the size of the window or monitor) and fitting components into that, by sizing to fit, or adding internal scrollbars where necessary. Some apps or parts of apps display documents or lists which almost always need scrollbars - browsers, IDEs, or word processors are pathological examples, but even there there are tabs or toolbars which don't scroll when you use the app.
These are somewhat contradictory viewpoints: either children pass sizes up to their parents, or parents instruct their children in sizes they may use. Supporting both simultaneously everywhere is clearly not reasonable, but some areas can be sizes top-down (add a viewport to the page, add a BorderLayoutContainer to the viewport...), while some can be bottom-up (add a FlowLayoutContainer to the west region of the BLC, add arbitrarily many Fields, FieldLabels, and instruct the FLC to draw scrollbars when too much contents are to be drawn). Designing an application UI is an exercise in deciding which tool should be used where, how much sizing should be done, and where scrollbars are or are not acceptable.
GXT is designed for application building, so it provides ways to build these application-style views and layouts with html/css document-style rules. Layout containers generally provide one or both of the two features of sizing and positioning to do their jobs. When one is not provided, generally html/css rules prevail.
VerticalLayoutContainer and HorizontalLayoutContainer both size _and_ position their elements. The exception is when -1 is provided as a size, meaning 'use the existing size of the child'. Some elements like another VLC or HLC may not yet have an existing size, as they haven't been rendered yet.
BorderLayoutContainer, CartLayoutContainer, SimpleContainer (and subclasses like Viewport) all size and postion their children, subject to layout data.
CssFloatLayoutContainer does a little of both - it allows multiple columns to be sized and positioned in terms of width and x position, but height and y position are left to the children - very tall children will result in the container trying to take up more space vertically. Enabling scrollbars is usually a good idea in this case.
FlowLayoutContainer entirely leaves sizing and positioning to html/css rules. Same with HtmlLayoutContainer.
10 May 2012 10:22 AM #8
To add one more comment to Colins post.
VerticalLayoutContainer uses the browser flow for its vertical layout, however HorizontalLayoutContainer uses absolute positioning. That also means that HorizontalLayoutContainer requires to have a height set. Else it will collapse to 0.