Skip to main content

Swing's Generic MVC interface

Posted by spix on September 8, 2009 at 11:34 PM PDT
Project URL

Go see Project Homepage


Expedite Swing Application development and best practices by using Generic Views, Models and Generic Controllers

There are many IDEs like NetBeans and Eclipse that allow using Drag and Drop building of sophisticated User interfaces (UI). Almost every aspect of the View can be manipulated and it is i.e. in Netbeans even possible to see the real thing by running the generated code.

The begist chalange is to incorporate business logic into the generated code in a mixture of JTables, JList JButton etc etc, and there are even things like TabbedPane which was and still is a daunting task. Several Framework have been developed like RichClient which seems or should overcome this problem.

This Proposal to the existing Swing library is to send out Generic Change notifications, not as currently as row numbers de pending on the actual View type but the actual Object instance itself. A type safe Generic Table Model Change message, which is just a POJO, informs any listener about the Objects that are i.e. added, deleted or updated. The other important message is a type safe POJO Selection change message which informs about the actual Object instances that are selected or deselected.

The other way around is also possible, those business objects that have a reference to Generic Table Selector can send messages to select or deselect certain Objects.

This change leads to a simplification of Controllers. Controllers won't know what kind or type of View or Model is actually sending these POJO messages.

Having these POJO controllers allows also writing of i.e. JUnit testcases of the business logic.

Also a new View Wrapper class which holds a reference to the actual business object, describes the how the business object is going to be presented in several different View types using annotations. When the business object is presented in a single line then the actual View Wrapper class defines an annotation that defines the renderer used. If the business object is going to be presented in a JTable, each getter defines also using annotations the column number, it resource name, if the column is editable or sortable etc etc.

The general approach is to extend the existing Swing package to allow a gradual transition to this new approach.

Also a demo application is going to be available to show these new capabilities and is to be like the Petstore Demo application. This demo will exists out of two Swing applications so that reqests fired from a more complicated Swing application to a server will complete when the request is accepted by the user on the Server Swing application which emulates a real life example.

This might be the first step of making Swing less row index driven, which seems to be an historic artifact that has never been been removed/refactored.

The Ultimate goal is to make Swing, if possible, a truly Object Oriented framework where no java.lang.Objects are used or any row indexes, to interface with the user that implements only Controller logic.

Also, from a Controller point of view the controller only see Generic DataModels and Generic Selection Models. It would be great if an IDE would have a view so that the developer can associate custom controllers to all available DataModels and SelectionModels. Until that happens, a simple wiring module could make all these models available through code like this

public class wire< E extends ViewModel> { protected E getPersonTableModel() {

return getPanel1().getPanel2........getPersonTable().getTableModel();


protected E getPersonSelectionModel() {

return getPanel1().getPanel2........getPersonTable().getSelectionModel();


public void registerToSelectionModel( SelectionModelObserver controller) {



// [snip] }

By using the annotations @Controller it would be possible to identify all the controllers in a project. This would allow an IDE to bind a Model or a SelectionModel to a Controller. All Generic data models would use the annotation @Model and Selection Models use the @SelectionModel annotation. This way a Controller can be bound to a list of selectable Models or SelectionModels: this would be i.e. used to select certain fields based on properties of the actual object instance. CardLayout could be considered to be SelectionModels: sometimes a certain object must be associated to a certain View/Panel in a (detail) CardLayout Panel. To a certain extend a set of checkboxes could also be considered as being a SelectionModel of which a Controller is able to pre-select certain set of buttons/checkboxes. Buttons are considered to be selection model only, it would be bad practice to let a Controller select a push button or change the Buttons datamodel..


GNU General Public License (GPL v. 3.0)
Related Topics >>