- You know your target domain or business logic, so that you are able to design expressive and concise domain objects.
- You are thinking in "swing models", not the UI-components. If you understand your domain, you probably have an idea as well how to visualize the business concepts in object oriented way. The use of Swing models just becomes natural.
- You are starting with the domain objects covered with unit tests, then develop the Swing models - after that the work is almost complete. You "only" have to create the view and pass the model to it.
- You are NOT trying to work with the views directly and force them to behave in your way. This could become quite complex, cumbersome and very hard to maintain. E.g. if you are working with the JTable directly, instead of TableModel, even reordering the table columns can cause you some headaches. The are no issues with a custom model in this case.
- The use of TableCellRenderers and TableCellEditors in JTables helps you to visualize you domain objects directly - without any overhead.
- You are using visual designers like e.g. Matisse in pragmatic way and separate the generated, from your code.
- You have a clear concept how to bind (e.g. with reflection+annotations or JSR-295) the UI-components to domain objects and how and where to validate the input (e.g. in controllers, domain objects or converters).
- Try to leverage existing JavaBean patterns like PropertyChangeListener, PropertyChangeSupport and the already built-in listeners in the UI-components. There is lot of stuff which can be reused.
- If you spend more, than half hour to solve a specific "Swing-problem", just stop hacking and use google to find a solution for your problem. There are amazingly good tutorials, articles and posts out there.
- If you loose your motivation. Just stop developing Swing, build a quick prototype with SWT/JFace for few hours (but use Tables and Trees). Your motivation should increase dramatically after this experiment :-)
NEW online workshop: WebStandards Igniter (online)