1. #1
    Sencha User
    Join Date
    Jan 2010
    Posts
    132
    Answers
    2
    Vote Rating
    1
    darkling235 is on a distinguished road

      0  

    Default Answered: Layout Architecture

    Answered: Layout Architecture


    This is a slightly theorectical question. Our original goal was to make the entire application resizable. To do this we had a Viewport at the hightest level and inside of it were a group of BorderLayoutContainers, VerticalLayoutContainers, and HorizontalLayoutContainers (basically we were trying to do top down structuring).

    The problem is that we're discovering things don't look good when they get really small. So my new task is to make everything still resizable BUT have a minimum size below which things can not shrink and scrollbars would be created like a tradition web page viewed on a monitor with poor resolution. I've spent some time trying to think of ways to do this but they've all been pretty complicated and essentially variations on the theme "draw the page, measure each component and if its pixel size is too small, force it to redraw bigger." I'm thinking I'd probably stick the minimum size on the panels rather than the widgets but I'm unclear if this is the right design pattern.

    It feels like I'm trying to mix top down and bottom up layout styles which makes me wonder if I'm going down the wrong path.

    I'm hoping that there's a simple solution which I'm just overlooking. If anyone else whose dealt with this issue before could tell me how they solved the problem I'd greatly appreciate it.

  2. I THINK the remaing problem is that since BorderLayout asks its parent how big it is allowed to be and FlowLayoutContainer asks its children how big they need to be, neither one is actually telling anyone how big the page is.
    This is probably a problem. Technically, BorderLC doesn't ask its parent, but it expects its parent to *tell* it, and FlowLC doesn't tell its children anything.

    Instead of FlowLC, consider something like making a SimpleContainer subclass like MinSizeContainer, and override doLayout() to check the current size before passing something down to the children.

    In any case, only a parent with the css property 'overflow' set to 'auto' or 'scroll' is able to show a scrollbar. This property should be set on either the FlowLC or the hypothetical MinSizeContainer. This could either be toggled from 'visible' to 'scroll' when the browser window gets too small, or could be left on 'auto', only drawing a scrollbar when the child is bigger than there is space.

  3. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,640
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    I've spent some time trying to think of ways to do this but they've all been pretty complicated and essentially variations on the theme "draw the page, measure each component and if its pixel size is too small, force it to redraw bigger." I'm thinking I'd probably stick the minimum size on the panels rather than the widgets but I'm unclear if this is the right design pattern.
    Some libraries do offer such a tool, but you end up running in circles - measure the page, render components, measure components, re-render components. At best this is twice as many calculations as the layouts GXT currently supports, at worst you might need to iterate multiple times until you can get a consistent view of the numbers.

    One simpler idea could be to make a ResizeContainer subclass (or event handler?) that listens to the new size, compares against the smallest it is allowed to be, and then goes with scrollbars instead. This would make more sense to have at a higher level in the widget/layout tree, keyed to stop lower elements from needing a scrollbar. For a first try, I'd probably start with SimpleContainer, so as to have a single wrapper that makes this change, and insist that only one of these be inserted in the entire page. That point would be where the app would stop getting smaller, and stay stuck at the size given. This seems to fit the description you are asking for, though would be somewhat cumbersome to configure - instead of specifying a min size on each component and in each *LayoutData, you only set it once, knowing the details of sub-components.

    I've offered this solution several times to people (on IRC, in person) but never heard back - either it is just as easy as it sounds, or everyone got suddenly busy and was unable to come back and ask further questions about how to make it work.

  4. #3
    Sencha User
    Join Date
    Jan 2010
    Posts
    132
    Answers
    2
    Vote Rating
    1
    darkling235 is on a distinguished road

      0  

    Default


    I tried this approach and it does seem to work as far as it goes but it makes it mandatory that I find a way to manage the scrollbars as mentioned in my other post. I'm hoping to begin contrsuction on this system sometime this weekend and I'll report back with my findings

  5. #4
    Sencha User
    Join Date
    Jan 2010
    Posts
    132
    Answers
    2
    Vote Rating
    1
    darkling235 is on a distinguished road

      0  

    Default


    Ok I was able to lock the top level containers to the sizes I requested but I still have a problem.

    My new top level container is a FlowLayoutContainer (just inside the RootPanel) which contains a BorderLayoutContainer. They have both been perfectly sizes to 2420 x 1280 (I picked the numbers at random for my test) but there is no scrollbar so the content runs off the page. I THINK the remaing problem is that since BorderLayout asks its parent how big it is allowed to be and FlowLayoutContainer asks its children how big they need to be, neither one is actually telling anyone how big the page is.
    Now both layouts are locked to fixed pixel sizes and can't grow or shrink which is great but I still need a way to tell the FlowLayoutContainer to provide scroll bars. I'd prefer the FlowLayoutContainer to be the only one with scrollbars to avoid the "scroll panels within scroll panels" bug.

    This is the relevant portion of my code. Basically inside the borderLayout there are a couple of Vertical and HorizontalLayoutContainers and a few other items. I create my FlowLayoutContainer in changeToMonitorPage and my BorderLayoutContainer in createMainPage(). They are both set to fixed sizes. I also overrode OnResize for BorderLayoutContainer as an attempt to stop it from resizing. Any insight would be greatly appreciated. Thank you

    Code:
        public static void changeToMonitorPage()
        {
    
                RootPanel.get().clear();
                BorderLayoutContainer c =    createMonitoringTab();
                //if(menu != null)
                    //menu.destroy();
                
                v = new FlowLayoutContainer();            
                v.setPixelSize(SizeSensativePanel.minWidth, SizeSensativePanel.minHeight);
                v.add(c);
                RootPanel.get().add(v);    
                tab.hideHeaders(); //hack. This is done because the buttons are twitchy and don't hide well before being drawn in this version
                monitoringCenterPanel.forceLayout(); //this is another hack dealing the OrgChart which tends to not play well with the rendering engine
                forceChartRedraw(); //another hack dealing with Charts not being drawn properly due to the OrgChart moving them
        }

    Code:
        /**
         * Called when we switch to the Monitoring tab
         * @return
         */
        public static BorderLayoutContainer createMonitoringTab()
        {
    
            ScaleBaseOrgChart.destroy(); //ScaleBaseorgChart uses unstable external JS code and needs to be finnessed in order to work properly
            mainPageWidget = null;
            page = createMainPage();            
            monitoringCenterPanel = createMonitoringMainContainer();
            VerticalLayoutData monitoringLD = new VerticalLayoutData(1,1);
            page.setCenterWidget(monitoringCenterPanel, monitoringLD);
            
            return page;
        }
    Code:
    /**
         * Work function which creates most of the page.
         * We use a BorderLayoutContainer with the tree on the left side.
         * and the top layout (buttons and logo) on the top. In the monitoring page
         * we have the OrgChart and a set of graphs for the center widget.
         * We originally tried making the graphs the East widget but didn't care for the way it looked
         * 
         * On the system page the Layout has Tree and TopLayout but the center widget is determined by context
         * @return
         */
        public static BorderLayoutContainer createMainPage()
        {
            if(page == null)
            {
                page = new BorderLayoutContainer()
                {
                    @Override
                    public void onAttach()
                    {
                        super.onAttach();
                        //ContextMenu menu = new ContextMenu(this);
                        //startGraph();
                    } 
                    
                    public  native void startGraph() /*-{
                    $wnd.init();
                    }-*/;
                    
                    @Override
                    public void onResize()
                    {
                        
                    }
                };
                page.setPixelSize(SizeSensativePanel.minWidth, SizeSensativePanel.minHeight);
                BorderLayoutData treeSplit = new BorderLayoutData(.13);
                treeSplit.setSplit(true);
                tab = new TreeTab();
                page.setWestWidget(tab, treeSplit);
                page.setStyleName("monitoringPage");
                HorizontalLayoutContainer topLayout = createMainButtons();
                topLayout.setStyleName("mainPageTop");
                page.setNorthWidget(topLayout, new BorderLayoutData(68));
            }
            return page;
        }

  6. #5
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,640
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    I THINK the remaing problem is that since BorderLayout asks its parent how big it is allowed to be and FlowLayoutContainer asks its children how big they need to be, neither one is actually telling anyone how big the page is.
    This is probably a problem. Technically, BorderLC doesn't ask its parent, but it expects its parent to *tell* it, and FlowLC doesn't tell its children anything.

    Instead of FlowLC, consider something like making a SimpleContainer subclass like MinSizeContainer, and override doLayout() to check the current size before passing something down to the children.

    In any case, only a parent with the css property 'overflow' set to 'auto' or 'scroll' is able to show a scrollbar. This property should be set on either the FlowLC or the hypothetical MinSizeContainer. This could either be toggled from 'visible' to 'scroll' when the browser window gets too small, or could be left on 'auto', only drawing a scrollbar when the child is bigger than there is space.

  7. #6
    Sencha User
    Join Date
    Jan 2010
    Posts
    132
    Answers
    2
    Vote Rating
    1
    darkling235 is on a distinguished road

      0  

    Default


    That worked wonderfully thank you. We now have the size sensitive panel that lets things grow but not shrink. However we may lock it down into fixed size for the time being.

  8. #7
    Sencha Premium Member
    Join Date
    Jul 2011
    Posts
    21
    Answers
    1
    Vote Rating
    0
    Cloudgatherer is on a distinguished road

      0  

    Default


    Quote Originally Posted by Colin Alworth View Post
    Instead of FlowLC, consider something like making a SimpleContainer subclass like MinSizeContainer, and override doLayout() to check the current size before passing something down to the children.
    I'm having a similar problem as what is being described by darkling235 and I was wondering if you might elaborate on this solution. A cursory implementation of something like the following yields a couple problems:
    Code:
    @Override
     protected void doLayout() {
        int desiredHeight = getMinHeight() > 0 && getOffsetHeight() < getMinHeight() ? getMinHeight() : getOffsetHeight();
        int desiredWidth = getMinWidth() > 0 && getOffsetWidth() < getMinWidth() ? getMinWidth() : getOffsetWidth();
            
        this.setPixelSize(desiredWidth, desiredHeight);
            
        super.doLayout();
    }
    Where getMinHeight/Width are the desired minimums (or 0 if no minimum).

    The first problem I observe is that when this MinSizeSimpleContainer is placed within a container that has scrolling, the scroll bar overlaps with a portion of the MinSizeSimpleContainer.

    The second problem I observe is that if there are multiple containers that might support scrolling, the "outer" one seems to win. This might be more general of a problem.

    Thanks.

  9. #8
    Sencha User
    Join Date
    Jan 2010
    Posts
    132
    Answers
    2
    Vote Rating
    1
    darkling235 is on a distinguished road

      0  

    Default


    Without seeing the code I can't be sure but one problem I had was dealing with the containers that asked their parents how big to be and the ones that asked their children how big they should be. You may not have them set up right for the Size Sensative Panel to be the one in control and tell it's children they don't need to have scrollbars.

    For this to work properly you'd put the size sensative panel inside a viewport and have the size sensative panel get its size either from the viewport or override what the viewport says. Inside the size sensative panel you want all layout containers to be top down and ask the Size Sensative panel how much space has been allocated.

    That solved our major scrollbar issue

  10. #9
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,640
    Answers
    107
    Vote Rating
    80
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    One issue I see is that doLayout is then setting its *own* size again, which probably causes another doLayout. Instead, as a container, this should probably be sizing its child.

    The second problem I observe is that if there are multiple containers that might support scrolling, the "outer" one seems to win. This might be more general of a problem.
    This seems logical - if the outer one is told that it only has so much space, it will tell its children more space so that scrollbars are visible, so those inner children in theory don't ever bump into this issue. Nested scrollbars are very non-user-friendly, avoid them where ever possible. This 'MinSizeLayoutContainer' should never be nested, even with other children in the way.

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar