Presentation Logic Controller
How to reduce the impact on testability incurred by generated GUI code
When creating a Graphical User Interface (GUI) in Java it is common to use GUI builder tools like e.g. Matisse. These tools generate code that is difficult to change and debug without the tool and (afaik) impossible to test. To improve testability is it recommended to use the GUI builder only for the actual layout and such. Everything that even remotely resemble logic (yes, also view logic) can be split out to a separate controller. (This will give an extra "controller" in addition to the controller for the MVC pattern.)
Presentation Logic Controller
The MVC-controller has a reference to the data model and references to one or more Presentation Logic Controllers (PLC). Each PLC use a bindingSource to fetch data from an entity. The PLC is given the responsibility of handling presentation logic (e.g. enabling/disabling buttons). The PLC is appropriate when the GUI has a complex relationship with the data model.
Is this the same as has been described in Decoupling presentation logic with MVP?
Could you have solved the same problem with Blackboard? (The various GUI-elements that read and write the same data (spread across different data objects) can work on a Blackboard.
Roadmap for Windows Forms data binding
Fixtures for Easy Software Testing (FEST)
Using Abbot and TestNG to test Swing GUI.
FEST project at Google Code Article Test-driven GUI development with FEST by Alex Ruiz Test-Driven GUI Development with TestNG and Abbot