Results 1 to 2 of 2

Thread: CSS and GXT 3.0.1

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Sencha User
    Join Date
    Jan 2010
    Vote Rating

    Default Answered: CSS and GXT 3.0.1

    I've always had trouble using CSS with GXT but since 3.0.1 I'm really really struggling. I'm not sure how to go about several issues, most pressingly, how to set the size of Fields and how they are arranged (i.e. these three fields share one row this one has a row to itself, or this FieldLabel should occupy 100% of the row and this one should wrap after 50%).

    Also I'm struggling to set relative sizes for things. Sometimes it seems like when I setWidth() equal to 50% or something that it's largely ignored. Using fixed sizes always seems to work but relative sizes seems hit or miss. I think this is because of some of the dynamically generated divs that appear as children of the panel I created. The seem to have dynamically generated style names which makes the size hard to style in my own CSS.

    Are there any good resources saying which CSS properties GXT reads to structure the widgets and panels? Or good resources for the new Appearance pattern stuff? I only found one blog on the Appearance but it seems more geared toward rewriting the appearance than modifying it. We don't want to change much, just to modify the positioning and sizing and I really don't want to have to write the HTML code to do it.

    Any help would be most appreciated!

  2. Are there any good resources saying which CSS properties GXT reads to structure the widgets and panels?
    I think this is the most important misconception in your post, and I'm hoping I can clarify it completely. From there, it will hopefully be a matter of explaining how instead you should be positioning and sizing things.

    The answer is no, because GXT doesn't read CSS - the browser does.

    GXT does not use CSS as a set of guidelines, because HTML and CSS really are not designed to be tools to build applications with - they are great for documents (start at the top, read left to right or right to left, and work your way down the page, scrolling as you go), but not applications (work within the available space, each container subdivides the space it has for its children).

    Instead, GXT provides containers that, with some configuration, use their own css to direct the browser to position elements as you've requested.

    GWT's Widget (okay, Widget's superclass, UiObject) class provides setHeight(String) and setWidth(String), as well as setSize(String, String) - these directly manipulate CSS, and in doing so prevent you from taking advantage of GXT's layout system. This isn't necessarily a problem - CSS might be able to solve your problem - but given how CSS parses out percentages, it might not.

    UiObject also supports a few more methods that refer to sizes, but only take pixels as ints. These methods, setHeight(int), setWidth(int), and setPixelSize(int,int) eventually cause the styles to be changed, but in the case of GXT components, can also be used to notify child widgets that their size should *also* change. Typically, you should tend to use these when setting specific sizes.

    Some widgets, like the Horizontal and VerticalLayoutContainers, as well as Grid, really don't behave well without a size assigned. Others, like Fields (and FieldLabel) can be decide their own size, can be given a height/width, or just can be given a width and will decide their own height. In some parent containers, it is easy to add a scrollbar if something needs more room than is available (specifically try to use FlowLayoutContainer or CssFloatLayoutContainer for these).

    Several containers accept three ranges of values - numbers greater than 1 are specific pixels, values between 0.0 and 1.0 are percentages, and -1 means 'ask the child how much space it needs'. HLC, VLC, and CssFloatLC are three that can use this.

    For the case of assigning percentage widths, but letting the children determine their own height, CssFloatLC is almost certainly the right answer. Try something like this for your initial use cases (that said, i'm not sure what you mean by 'should wrap after 50%'):

    public class Test implements EntryPoint {
      public void onModuleLoad() {
        CssFloatLayoutContainer outerContainer = new CssFloatLayoutContainer();
        //row 1, all percentages add up to 100%
        CssFloatLayoutContainer r1 = new CssFloatLayoutContainer();
        r1.add(new FieldLabel(new TextField(), "25%"), new CssFloatData(.25));
        r1.add(new FieldLabel(new TextField(), "25%"), new CssFloatData(.25));
        r1.add(new FieldLabel(new TextField(), "50%"), new CssFloatData(.5));
        outerContainer.add(r1, new CssFloatData(1.0));
        //row all by itself, since 100% is all the space - no need for a row
        outerContainer.add(new FieldLabel(new TextField(), "100%"), new CssFloatData(1.0));
        // row 3, basically the same as row 1
        CssFloatLayoutContainer r3 = new CssFloatLayoutContainer();
        r3.add(new FieldLabel(new TextField(), "25%"), new CssFloatData(.25));
        r3.add(new FieldLabel(new TextField(), "50%"), new CssFloatData(.5));
        r3.add(new FieldLabel(new TextField(), "25%"), new CssFloatData(.25));
        outerContainer.add(r3, new CssFloatData(1.0));
        //row 4, using pixel sizes for two, then the third using what is leftover
        CssFloatLayoutContainer r4 = new CssFloatLayoutContainer();
        r4.add(new FieldLabel(new TextField(), "300px"), new CssFloatData(300));
        r4.add(new FieldLabel(new TextField(), "300px"), new CssFloatData(300));
        r4.add(new FieldLabel(new TextField(), "100%"), new CssFloatData(1.0));
        outerContainer.add(r4, new CssFloatData(1.0));
        //Adding to a Viewport, because Viewport always consumes all space available
        Viewport vp = new Viewport();
        //Adding vp to page
    Make sure to resize the page to get the full point/effect. Note also that containers for child rows are only required because of the last child - if you got rid of row 4 and its need to have both fixed and dynamic widths (i.e. so all rows used dynamic widths) only one container is needed. This is due to how the sizes have to be allocated, and how the CssFloatLC works - it sets sizes, and lets the css float:left property position them.

Tags for this Thread

Posting Permissions

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