Standard way of adding Swing components to a container?

Question

I've searched around but couldn't really hit the nail on the head to this question.

I am not sure that my current strategy of adding lots of components to my UI's would be fully understood by other programmers at first glance. I do a lot of Swing work (mostly for my personal applications) so of course my process is what I'm used to.

Essentially, I like to create all the components (maybe not in order, sometimes my thinking isn't 100% linear and correct from the beginning). I may or may not go back and order them nicely.

However, I do make sure to add them in an order that is somewhat reminiscent of a web page. Almost always at the end of the method where they're created.

Is there a standard way to add components to containers in Swing? I have seen people add components seemingly willy-nilly throughout their code, and if I need to adjust a component, sometimes it is hard to find. I try to keep that part centralized and add them to their containers in a sensible way.

Example:

public void populateMyPanel()
{
    // Create all components
    JPanel wrapperPanel new JPanel(new BorderLayout());

    JPanel panelWest = new JPanel(new FlowLayout());
    JLabel labelOne = new JLabel("Label #1");
    JButton buttonOne = new JButton("Button #1");

    JPanel panelCenter = new JPanel(new FlowLayout());
    JButton buttonTwo = new JButton("Button #2");

    JPanel panelEast = new JPanel(new FlowLayout());
    JTextField myTextField = new JTextField();
    JButton buttonThree = new JButton("Button #3");

    // Now add them in a top-to-bottom & left-to-right order
    wrapperPanel.add(panelWest, BorderLayout.WEST);
      panelWest.add(labelOne);
      panelWest.add(buttonOne);

    wrapperPanel.add(panelCenter, BorderLayout.CENTER);
      panelCenter.add(buttonTwo);

    wrapperPanel.add(panelEast, BorderLayout.EAST);
      panelEast.add(myTextField);
      panelEast.add(buttonThree);
}

Answer 1

For starters, follow the principle of least astonishment: if you're working with others, and they've already established a convention, use theirs. I've seen people who code very much like the example you've given. I've seen others declare but not initialize objects up towards the top of the class and then initialize them later in one method and add them to panels in yet another. There's probably three dozen other ways of doing the same thing and a valid argument for each.

That said, much of the hair-pulling of laying out objects can be alleviated by choosing the best layout manager for the job. Ever since the first project I tried it on benefited so much from it, I've been strongly biased towards using MigLayout ( http://www.miglayout.com/ ), but I'll admit it may be overkill for simple cases. Take a look at their quick-start guide & Swing demo (shows both what it can do and the code to do it) and see if it makes sense to you.

Answer 2

The question is contextual, sometimes, you would create your components in visual order, some times you would create them in needs order (so a component that visually appears after another would be created first because it is need for some reason).

The only suggestions I can make would be to limit the mess. If you are creating multiple containers, it might be worth while creating one or more (factory) methods which are responsible for doing the heavy lifting. This reduces the clutter and makes it a little easier to separate the visual/logical connection between UI elements.

If the relationship of a given container(s) are complex, it might even be better to create a separate class for them, so as to isolate the management into a single class. This could be an inner or outer class depending on your needs. This makes it easier to isolate the functionality required for a given series of components from the management of other components, which will help improve the understanding of the code.

Basically, there is no hard or fast rules for every case and you need to decide how best to manage it. Personally, I focus on areas of responsibility and exposure. Isolate the functional errors into management chucks, so the relationship/management/functionality is more easily understandable (and changeable/extendable) and isolate exposure where possible.

That is, if one part of your program doesn't care how the data is collected or managed, then it doesn't need to have access to the components that perform that functionality. This reduces some the complexity in understanding how various components inter-relate with each other - IMHO