Results 1 to 7 of 7

Thread: Nesting HorizontalLayoutContainer and VerticalLayoutContainer

  1. #1
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default Answered: Nesting HorizontalLayoutContainer and VerticalLayoutContainer

    Our firm is in the process of evaluating GXT to see if it meets our needs as a more up-to-date replacement for GWT-Ext.

    I seem to have hit on a stumbling block in the first very simple panel we were looking at migrating as a test of how the two fit together - Help about.

    I've pasted below a very cut down version of the code. The basic idea was to use nested horizontal and vertical layout containers to achieve the look e.g.

    - a horiz panel 1 which has left and right items, the right items themselves being stacked in a vert panel
    - an overall vert panel which contains the above plus further items beneath.

    The horizontal panel with nested vertical panel seems fine.

    But when further items are added to the overall vertical panel, they get overlaid on the horizontal panel rather than beneath it.

    Screenshot of how this looks:

    gxt_about.png

    Simplified code fragment:

    Code:
    public class AboutDialog extends Window
    {
    
        public AboutDialog() 
        {
            super();
            
            setWidth(400);
            setHeight(200);
            setHeadingText("Some Dialog");
            setModal(true);
            
            // Create a left hand side panel of 1 label
            HorizontalLayoutContainer h1 = new HorizontalLayoutContainer();
            h1.add(new Label("Left label 1................"));
            
            // Create a right hand side panel of 2 labels
            VerticalLayoutContainer v2 = new VerticalLayoutContainer();
            v2.add(new Label("Right label 1....."));
            v2.add(new Label("Right label 2....."));
            h1.add(v2);
    
            // Now create a vertical layout, with the above combined panel plus some other labels below it
            VerticalLayoutContainer v1 = new VerticalLayoutContainer();
            v1.add(h1);
            
            v1.add(new Label("...Lower label 1..."));
            v1.add(new Label("...Lower label 2..."));
            v1.add(new Label("...Lower label 3..."));
    
            add(v1);
          }
    
    }
    Reading this article here, there is a footnote on nesting limitations. But the above doesn't seem to violate that - the only widgets in play are either basic GWT labels or GXT layout containers. In fact our real example used images, HTML items and others which I suspected may be the issue. But removing these down to simple labels, the layout is exactly the same.

    I'm aware that there are many other ways to achieve the above simple layout. That's not really what I'm looking for here though - what I'd like to understand is why the nesting doesn't work. Is it a bug, something we're doing wrong, or a use case that simply won't ever work in GXT.

    The version supplied to us for this evaluation was the latest download one - 3.0.1. I realise there are more recent GXT versions, but these do not seem to be made available for evaluating users, so I'm not able to test if this is a bug that has been fixed which is also rather frustrating.
    Last edited by walkerr; 9 Oct 2013 at 10:32 PM. Reason: Removed incorrect screenshot attachment

  2. Assuming you want the user to size the Window and let those work their way down, giving sizes to the eventual children (probably not labels...), then HLC and VLC are for you (BLC may also be handy, hard to know without more specifics of the real use case), but layout data is essential. Avoiding magic numbers is great for pixel sizes, but percentages are a whole different story - if you want to split the space evenly between two items, assigning .5 to each seems perfectly reasonable. Then it won't matter how much space the parent has, it will be divided correctly among the children according to those rules.

  3. #2
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default

    Since we use several libs and styles in our App, I figured I should test the problem code completely standalone.

    So I created a basic GWT project in Eclipse (teh standard sample one which the plugin creates), stripped out the sample code, and just added back in the AboutDialog example.

    Same problem occurs, so I don't think it's any bleed through from other parts of our app.

    Example project attached - I don't normally work in Eclipse in this way so only stripped out parts I knew a build would recreate or could be easily re-added (gwt-unitCache, war/WEB-INF/lib/gwt-servlet.jar).
    Attached Files Attached Files

  4. #3
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default

    Thought I'd have one last go around with this and see if it behaved differently in UiBinder. Result is the same (code below)

    Code:
      <gxt:Window ui:field="window" pixelSize="400, 200" modal="true" blinkModal="true" >
      
        <cont:VerticalLayoutContainer>
    	    <cont:HorizontalLayoutContainer>
    	       <g:Label text="Left label 1 ......."/>
        
    	        <cont:VerticalLayoutContainer>
    	           <g:Label text="Right label 1 ......."/>
    	           <g:Label text="Right label 2 ......."/>
    	        </cont:VerticalLayoutContainer>
            </cont:HorizontalLayoutContainer>
    
            <g:Label text=" .... Lower label 1 ......."/>
            <g:Label text=" .... Lower label 2 ......."/>
            <g:Label text=" .... Lower label 3 ......."/>
    
        
        </cont:VerticalLayoutContainer>
        
      </gxt:Window>
    Have to confess to being rather disappointed in response from Sencha to this one, or my direct email to confirm rumoured upcoming price changes for GXT.

    As someone that has been charged with evaluating GXT and SmartGWT, my natural leaning was towards GXT as being a pure GWT solution and UiBinder compatible. But layouts that don't work, old versions supplied for evaluation, and a lack of responses from the supplier doesn't make it an easy recommendation for me to make to my firm.

    Is this normal/typical for Sencha and GXT?

  5. #4
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737
    Answers
    109

    Default

    From the doc you linked:
    Sizing explicitly or implicitly

    Many components or containers need sizes to do their jobs correctly - Grid, Tree, HorizontalLayoutContainer, and BorderLayoutContainer are a few such examples. It isnt necessary to always invoke component.setPixelSize or component.setSize on these directly, but if they are not explicitly given a size in this way, they must be sized by their parent to function correctly.
    The HLC (and then inside of that, VLC) in your code is not being sized, because you've added it to the outer VLC directly, with no layout data. This is almost certainly the source of your problem. This will remain true for any version of GXT, because the VLC and HLC are built to provide specific functionality - subdivide space from the parent to the children, based on specific rules. Those rules allow for sizes to be specified in pixels (greater than 1) and percentages (0.0 to 1.0), as well as using the 'default' or 'natural' size of a child (-1, or no layout data at all).

    The http://docs.sencha.com/gxt-guides/3/...Container.html document also touches on this, giving the specifics of those values, and what they mean. Since you are giving outer VLC and inner HLC no layout data for their children, they get a -1 value for width and height, and so are only ever *measured* to possibly account for other children (which there are none), but never sized. Without a size, even if the HLC or inner VLC were given layout data themselves, they wouldn't be able to sub-divide it to size their children accordingly.

    http://www.sencha.com/examples/#Exam...rizontallayout and http://www.sencha.com/examples/#Exam...%28uibinder%29 both show how to apply layout data to an HLC, one in java, and the other in uibinder.

    The basic idea was to use nested horizontal and vertical layout containers to achieve the look e.g.

    - a horiz panel 1 which has left and right items, the right items themselves being stacked in a vert panel
    - an overall vert panel which contains the above plus further items beneath.
    Should this size itself based on the space in the parent? If so, the containers you've selected are a good fit - decide what percentage of the available height in the window should the HLC use versus the labels at the bottom and assign layout data at the outer VLC, then do the same within the HLC, etc. Or should they simple stack and use the layouts they need? If the latter, looking back at the main layout concepts doc, this would be a document layout, not an application layout - you will likely find the FlowLC or CssFloatLC as a better fit. It may also be reasonable to mix and match, but without a clearer picture of how the parents should size the children, or the children should make space in the parent, it is hard to know what exactly to tell you.

    Here's another perspective to consider - when the window is resized, how should the contents respond? Understanding that will help lead you in the right direction to decide which layouts to use and how to use them.

  6. #5
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default

    Ok, thanks Colin, Makes sense. Will give it a try.

    And yes, the idea was to subdivide parent size and have it ripple down and adjust if resized. So it sounds like we were on the right track, albeit without having set the outer sizing properly.

    The one thing I really want to avoid is having too many sizes floating around the code. Ideally we'd just size the outer Window and have everything ripple down from there. In our app, we persist sizes if users change things, so on later restarts of the app the Window size will be different if changed by the user, hence not wanting too many "magic number" sizings happening being done in the code.

  7. #6
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737
    Answers
    109

    Default

    Assuming you want the user to size the Window and let those work their way down, giving sizes to the eventual children (probably not labels...), then HLC and VLC are for you (BLC may also be handy, hard to know without more specifics of the real use case), but layout data is essential. Avoiding magic numbers is great for pixel sizes, but percentages are a whole different story - if you want to split the space evenly between two items, assigning .5 to each seems perfectly reasonable. Then it won't matter how much space the parent has, it will be divided correctly among the children according to those rules.

  8. #7
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default

    Ok, that sounds like good advice, thanks.

    I haven't tried these ideas yet, but they point me in the right direction so I'll mark this thread as answered to reduce the clutter.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •