Q:

Java Swing: separating UI component from logic behaviour - how do you approach this?

What I do, in NetBeans for example:

create a UI component class, suffixed with Swing component type, e.g. JPanel, e.g. MyUIWidgetJPanel
create a logic/behaviour class to handle the behaviour/logic, i.e. what happens when the UI component is used, e.g. buttons within it pressed etc., MyUIWidgetLogic

I may also link components/logic together using references, if the behaviour/outcome of one component influences/impacts another, e.g. some options displayed are no longer relevant, or to give context sensitive options.
What do you think of this? Good? Bad?
What do you do?

A:

I tend to use the Presentation Model Pattern.
Essentially it seems to be what you do: create a class which encompasses the logic, separate to the UI class. The UI  classes shouldn't contain logic - only the code needed to display the interface.
You can then bind your front-end values to the back-end presentation model class using something like JGoodies Binding (I understand that Spring RCP is pretty good for this as well).

A:

I found this article How to Write Custom Swing Component helpful as an example of UI delegate plumbing.
Filthy Rich Clients by Chet Haase and Romain Guy is widely recommended for tips on visually rich client applications.

