We Keep Coding

Why use CustomComponent for Layouts in Vaadin 7?

Both the Book of Vaadin and the Vaadin training course recommend using acom.vaadin.ui.CustomComponent to contain a Layout.
I can understand this in pure theory, to encapsulate the contents without needlessly exposing a specific layout such as GridLayout or HorizontalLayout. Encapsulating has benefits of:
Encouraging de-coupling between classes
Makes it easier to change the layout without having to change the declarations in the outer class.
But in terms of practicality, I assume the rendering of a CustomComponent means extra HTML/CSS layout instructions such as perhaps an another div. The last thing Vaadin rendering needs is yet another layering of HTML structure.
I wonder if this might be old folklore. Perhaps using the visual composing tool in Eclipse accepts only CustomComponent objects rather than Layout objects? (Just a wild guess, I have no knowledge)
➤ Alternatively, why not just declare in the outer class a reference variable of type com.vaadin.ui.Layout to get the same encapsulation?
➤ Am I exaggerating the impact of adding a CustomComponent to Vaadin rendering?
➤ Is there some other benefit of CustomComponent which I’ve failed to perceive?

You can compose the content of a CustomComponent with the Visual Designer. This saves a lot of time in the development process

The main advantage of the CustomLayout is, that you can place your components inside HTML code which you otherwise can't generate via vaadin means.
If this adds more div/html as with native Layouts depends on the specific case.
We ususally use it only when a clean Vaadin only solution would introduce more components/div's or is not possible to implement.
The second idea is the separation of layout and logic, which can be implemented partially with this Layout. You just specify which components you have and then a UI designer (in theorie) could make your HTML code, with the correct blocks where your components will be placed.
In real life I do not find this a real advantage, since the whole CSS, sizing etc. is anyway done with vaadin.

How to create a modular UI using MigLayout without nesting multiple panels?

MigLayout is a highly versatile layout manager for Swing, SWT and JavaFX.
As per the documentation, it should be possible to (re-)create any given layout with just a single instance of that layout manager.
However, I could never figure out how to create a modular application with decentralized control over layouting with that single instance:
I have a parent panel that controls where individual components contributed by submodules go.
Aiming for decoupled and independent submodules, those components are free to choose whether they do their layout with MigLayout or with any given layout manager. Thus, they hand out an instance of Node (or JComponent), and I end up with nested layout managers.
Are there any emergent/good/best practices for achieving both decoupled architecture and adhering to MigLayout's single-instance paradigm?

I understand what you want to do and have tried similar approaches. I found no generic solution; either you nest the layouts or you come to some kind of agreement between modules on usages of ranges of cells (this is what I usually end up with when for example generating search screens).
I ended up with one conclusion; having totally independent modules putting stuff on a screen works fine technically, and if you can make a high degree of separation part of the layout style, it might also work for the user. But I found that the resulting screens usually are not very user friendly, especially if there are multiple layers of construction. So I stopped trying to dynamically construct screens and just build a screen to match the task at hand; there is the end user screen, some custom controls, and maybe the occasional task specific panel (/ pane).

What is the best way to manage application screens in SWT?

I'm creating a standalone SWT desktop application that has around 10 different screens (few wizards, help, forms, etc). Some elements on screen don't change at all (like header, background, etc) and there is a working area that changes depending on what is clicked, etc.
What is the best way to manage application screens? Do I need to create all screen at startup and then show/hide them depending on what is clicked? Or do I need to create those screens dynamically?
Also, I couldn't find any way to show/hide a Composite, do I need to dispose it and then create again?
What is the best practice? I'm new to SWT developing outside of Eclipse so any help would be beneficial.

Deciding whether to create screens up front or creating them the first time they need to be displayed is a decision that needs to be made on a per application basis. If there is a good chance that all the screens are going to need to be used on a particular application run and the number of screens is low (10 screens is relatively low) then you may want to create them at application startup so the UI is snappier once the application loads.
If you use bindings then you may need to come up with a dispose strategy (even if you only dispose the bindings) so you don't have too many events flying around.
Control has a setVisible(boolean) method (and Composite inherits from Control) which you can use to show and hide a component. Note this will only prevent the composite from being shown on the screen, the layout manager will still allocate a blank space for it. Many SWT layouts have a way to exclude a control from the layout which will get rid of the blank space. For example if you are using GridLayout then you would set the exclude variable on you GridData object to true when you hide that control.
Another option is to use StackLayout. This lets you stack a bunch of Composites on top of each other and then choose which on is on top. This might be a good fit for you if you have static areas plus a working area like you described. I would put the header, footer, and an empty composite with a StackLayout in a class file. I would then put each screen that will be displayed in the working area in their own classes. You can either have these screen classes extend Composite and then set up themselves in the constructor or you can use a factory method to setup the screen. Either one is a common and acceptable practice and comes down to a matter of taste.

NetBeans should be named "Mexican Jumping Beans"

I have been trying to set up a Java form in NetBeans with 15 - 20 visual components (buttons, textfields, etc.) and I have been using the Free Design layout paradigm on the MAC.
According to what I've read, the Free Design layout gives me various alignment guides, but does not try to force my alignments to specific row and column delimiters. However, I'm finding that when I do this, the width of my form may arbitrarily change, or some of the components I've already placed will move around radically when I make even small adjustments to other component positions.
Is there some way to anchor all these components, once placed, or is there a better layout paradigm that gives me the freedom to place components where I wish to?

IMHO, Matisse works best when you know what you want before you start. It doesn't seem to do so well with iterative changes.
Here are a few rules I follow when using Matisse in freeform mode. They don't make it wonderful, just less painful:
Build top-to-bottom and left-to-right. Most jumping happens when you go back an try to insert something.
Build it in one pass.
When you make progress, save it. There are conditions where Matisse will drop its undo list. Don't count on Ctrl-Z to bail you out. I use a local mercurial repo to track my changes.
Keep it small. The more elements, the more likely it is to blow up. Build it out of smaller components. For example, if you have a date field with a button to open a calendar
make that a component.
Add the component to the palette,
use that in the larger component.

Maybe it's time to look into other LayoutManagers, like GridBag or something else that will give you what you want. The built-in choice by NetBeans sounds like a poor one for your needs.
If you choose a null LayoutManager you'll get absolute positioning.
But along with it comes absolute responsibility: No help in repositioning any elements.

I've found Using GroupLayout directly works really well. It can be confusing at first because horizontal and vertical layout are done separately, but once you get used to it it's not that difficult. You can definitely get things to align, and stick together when resizing. It's far better then using nested panels, GridBags, and that kind of thing.
MigLayout might work too, but GroupLayout is included in the JDK.

You may want to look at the absolute layout. It allows you to put the component exactly where you want it, without all the jumping around.

GridBag Layout is my favorite, and specially in Matisse (Netbeans GUI). You have like a wizard to graphically manage all the properties.
Will take you few examples to get things perfect as you want, but when you do, you will never look back.
Take a look at Sun Tutorials GridBag Layout

I strongly, strongly recommend MigLayout (And getting away from GUI layout tools). Any time you think you are saving by using a GUI tool quickly evaporates the second you run into layout manager behavior. Real UI's are coded, not built with drag and drop.
I found that it took me about 3 hours of fiddling to get used to MigLayout - after that break in period, I found it to be incredibly intuitive and powerful.

Java GUI LayoutManagers

I'm busy with an asignment where i have to make a graphical interface for a simple program. But i'm strugling with the layout.
This is the idea:
What is the easiest way to accomplish such a layout?
And what method do you use to make layouts in java. Just code it, or use an IDE like netbeans?

And what method do you use to make layouts in java. Just code it, or use an IDE like netbeans?
NetBeans for GUI developers is like a calculator for grade schoolers: you really shouldn't use it until you know how to do things without it, but then it will save you a lot of time.
(I'd love to answer your primary question, but the firewall I'm behind is blocking the picture.)

Well considering how simple the layout is I would suggest you use a BorderLayout with NORTH set to the top section in a container and the JTable in the CENTER of the BorderLayout. For the Top it appears to be a simple BorderLayout again with NORTH as the Instruction: south as the black box (possibly in a container with a FlowLayout). The center of the top pane appears to be 2 Containers of GridLayouts with 2 rows and 2 columns, so put thos in another container with a GirdLayout.
So in pseudo:
Container(BorderLayout)
{
#NORTH
Container(BorderLayout)
{
#NORTH
Label(Instruction);
#CENTER
Container(GridLayout(2,1))
{
Container(GirdLayout(2,2))
{
Label() TextField()
Label() TextField()
}
Container(GirdLayout(2,2))
{
Label() TextField()
Label() TextField()
}
}
#SOUTH
Container(FlowLayout())
{
JButton() //shaded thing?
}
}
#CENTER
{
JTable
}
}

I build everything by hand. Like Christian, I've had bad experiences with GUI builders; they always either refused to configure a couple of components quite right, or they generated huge amounts of unnecessary code which made later maintenance impractical, or both.
I used to do build a lot of UIs using GridBagLayout, but for years, I've never seen an office-environment UI that couldn't be built with nested BorderLayouts, GridLayouts, and the occasional BoxLayout or FlowLayout. About 98% of the stuff I've seen is doable with nested BorderLayouts.
In your case, the layout organization will be as bmeck says. Speaking from memory, using CENTER for the JTable (remember to put it in a JScrollPane!) and NORTH for everything else ensures that if you resize your JFrame, the JTable will get all of the extra space, and that should be exactly what you want. For the top labels and fields, the nested GridLayouts should ensure that each "column" of labels and fields will take up equal horizontal space. (They'll get only enough vertical space to be completely visible, and no more, since the JTable is taking up everything else.)
Everything else is just a matter of adding borders and setting the GridLayout padding reasonably.

For myself gui-builders for swing or swt never worked that well that's why i code layouts myself using layout managers.
Your question doesn't mention which gui-system you are using but i assume you want to use swing. If that's the case I would recommend to use GridBagLayout for your layout. It is not that easy to use in the beginning but as soon as you know how it works you can do most layouts in the way you want it to be and i think it is also the layoutmanager of choice for the layout you want to do.

I've used GUI layout generating tools for super rapid development (maybe get the first 2 or 3 iterations of an interface out of the way). I've ultimately found that using a simple fixed layout (no layout manager) with these tools is the best approach. Once we are starting to hone in on a design, we switch to manual layout.
Whenever I've tried to use GUI generators to create code for layout managers, I've almost always been bitten eventually where the layout would just stop working and I spent more time debugging the impossible to read auto-generated code than if I'd done the layout by hand anyway. For what it's worth, when we are doing the early phase of layouts, we use the Jigloo plugin for Eclipse. It's very inexpensive, and does a good job.
I'm a big fan of MiGLayout. I've found that it is incredibly easy to use for simple layouts, and is capable of doing extremely complicated layouts. All without the need to resort to nested panels, etc... JGoodies Forms is also good, but harder to use.

I wrote an article a while back on layout managers:
http://developer.java.sun.com/developer/onlineTraining/GUI/AWTLayoutMgr
It describes how nesting (as bmeck above demonstrates) can be used very effectively for many UI designs.

Try table layout. Works great.
https://tablelayout.dev.java.net/

Use GroupLayout
:)
All the alignments are pretty easy to do

I used to love Motif's XmForm for this sort of thing. In Java, I usually put Boxes inside of boxes. So I have a vertical box. First row of the box contains a JLabel for the Instruction. Second row contains something for the label/result stuff, possibly some sort of grid. Third row contains whatever that blacked out thing, Fourth row contains the JTable. Then I'd spend some time to try to figure out how to do the lable/result stuff. Then I'd probably end up saying "dammit", and doing it as a GridBagLayout.