1. #1
    Sencha Premium Member
    Join Date
    Mar 2012
    Posts
    75
    Vote Rating
    2
    tby is on a distinguished road

      0  

    Default Nested Containers with RadioButtons break layout

    Nested Containers with RadioButtons break layout


    Code:

    VerticalLayoutContainer v = new VerticalLayoutContainer();
    v.setBorders(true);
    HorizontalLayoutContainer h = new HorizontalLayoutContainer();
    v.add(new FieldLabel(new TextField(), "Field"));
    Radio r1 = new Radio();
    r1.setBoxLabel("Radio 1");
    Radio r2 = new Radio();
    r2.setBoxLabel("Radio 2");
    h.add(r1);
    h.add(r2);
    v.add(h);

    Expected:
    The border of the vertical layout container contains the RadioButtons.

    Behavior:
    The RadioButtons are drawn outside the VerticalLayoutContainer:

    Bildschirmfoto 2012-05-09 um 09.09.29.png

  2. #2
    Sencha User WesleyMoy's Avatar
    Join Date
    Oct 2009
    Location
    Redwood City, California
    Posts
    402
    Vote Rating
    2
    WesleyMoy is on a distinguished road

      0  

    Default


    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.

  3. #3
    Sencha User WesleyMoy's Avatar
    Join Date
    Oct 2009
    Location
    Redwood City, California
    Posts
    402
    Vote Rating
    2
    WesleyMoy is on a distinguished road

      0  

    Default


    I've moved this thread to the GXT Discussion forum as it doesn't describe a GXT bug.

  4. #4
    Ext GWT Premium Member lefke123's Avatar
    Join Date
    Dec 2011
    Location
    Belgium
    Posts
    77
    Vote Rating
    3
    lefke123 is on a distinguished road

      0  

    Default


    Quote Originally Posted by WesleyMoy View Post
    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.
    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.

  5. #5
    Sencha Premium Member
    Join Date
    Mar 2012
    Posts
    75
    Vote Rating
    2
    tby is on a distinguished road

      0  

    Thumbs up


    +1

  6. #6
    Ext GWT Premium Member gdlm's Avatar
    Join Date
    Jan 2012
    Location
    Belgium
    Posts
    208
    Vote Rating
    4
    gdlm is on a distinguished road

      0  

    Thumbs up 100% agree

    100% agree


    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.
    I completely agree.
    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.
    Is there somewhere a list of containers that ARE meant to be sized by their contents?

  7. #7
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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.

  8. #8
    Software Architect
    Join Date
    Sep 2007
    Posts
    13,971
    Vote Rating
    132
    sven is a glorious beacon of light sven is a glorious beacon of light sven is a glorious beacon of light sven is a glorious beacon of light sven is a glorious beacon of light sven is a glorious beacon of light

      0  

    Default


    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.