Easy to Learn Java: Programming Articles, Examples and Tips

Start with Java in a few days with Java Lessons or Lectures

Home

Code Examples

Java Tools

More Java Tools!

Java Forum

All Java Tips

Books

Submit News
Search the site here...
Search...
 
Search the JavaFAQ.nu
1000 Java Tips ebook

1000 Java Tips - Click here for the high resolution copy!1000 Java Tips - Click here for the high resolution copy!

Java Screensaver, take it here

Free "1000 Java Tips" eBook is here! It is huge collection of big and small Java programming articles and tips. Please take your copy here.

Take your copy of free "Java Technology Screensaver"!.

Swing Dev with TableModel Free framework

JavaFAQ Home » Swing, AWT Go to all tips in Swing, AWT


Bookmark and Share

Free yourself from the burden of the TableModel

The "reintroduction of the Java™ Desktop" underscored this year's JavaOne conference. A renewed effort on Swing and GUI development doesn't come as welcome news to those of you who swore off Swing as too slow, too hard to use, or too ugly. Well, if you haven't worked with Swing lately, you'll be glad to hear that many of these problems have disappeared. Swing has been reworked to perform better and to take better advantage of the Java 2D API. The Swing developers have improved the look and feel support in 1.4 and even more so in the recently released 5.0. Swing is back and better than ever before.

What the Swing community needs right now are tools to make GUI development a smoother, easier process. And that's where this article comes in.

This article introduces the TableModel Free (TMF) framework, a GUI development package that relieves the need to create TableModels (which I'll call classic TableModels in this article to distinguish them from the new structures I introduce for the framework) for every JTable; in the process, you'll be able to make your JTables much more configurable and maintainable.

If you've ever used a JTable, you've also been forced to use a TableModel. You've probably also noticed that nearly all of the code in each TableModel is identical to the code in every other TableModel, and the code that is different doesn't really belong in a compiled Java class anyway. This article will dissect the current methods of TableModel/JTable design, illustrate the shortcomings of this design, and show how it hasn't accomplished the true goals of the Model-View-Controller (MVC) pattern. You will see the framework and code that makes up the TMF framework -- a combination of code that I've written and commonly used open source projects. With this framework, developers can reduce the size of a TableModel from hundreds of lines of code to a single line, and put the important table information in an external XML file. After reading this article, you will be able to manage your JTable's data using the single line of code shown here:

  
  TableUtilities.setViewToModel("tableconfig.xml", "My Table", 
    myJTable, CollectionUtilities.observableList(myData));
  

MVC problems with JTable and TableModel
MVC has become a very popular UI design pattern, as it cleanly separates out the business logic from the view of the data. Struts is a very good example of the MVC design in use on the Web. One of the big initial selling points of Swing was its use of the MVC -- separating the view from the model -- the idea being that the code was modular enough that you could swap out the view without changing any code in the model. I think anyone who has ever worked with JTables and TableModels will laugh and tell you that that's flat-out impossible. Ideally, using the MVC design pattern, a developer should be able to substitute a JList or a JComboBox for a JTable with no change to the code in the model representing the data. However, you can't do that in Swing. Swing makes it impossible to hot swap a JTable, JList, and JComboBox into an application, even if all three components were to provide views of the same data model. That's a big deficiency in the MVC design with Swing. If you want to swap a JList for a JTable, you must rewrite the entire model behind the view to accommodate it.

Another MVC deficiency specific to JTable/TableModel is the fact that the view does not update itself when the model changes. A developer must keep a reference of the model and call a function so that the model tells the view to update itself; ideally, however this should just happen without any additional code.

Ultimately, the problem with the design of the JTable and TableModel components is that they are too intertwined with one another. If you change code in the JTable, you need to make sure that you haven't broken your TableModel in the process, and vice versa. In what is supposed to be a design pattern built on modularity, the current implementation is more a design of dependencies.

The TMF framework better adheres to the MVC goals by more cleanly separating the tasks of the view and the model in a JTable. Though it doesn't reach the higher goal of making the components hot swappable, it is a step in the right direction.

Full text here


 Printer Friendly Page  Printer Friendly Page
 Send to a Friend  Send to a Friend

.. Bookmark and Share

Search here again if you need more info!
Custom Search



Home Code Examples Java Forum All Java Tips Books Submit News, Code... Search... Offshore Software Tech Doodling

RSS feed Java FAQ RSS feed Java FAQ News     

    RSS feed Java Forums RSS feed Java Forums

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest 1999-2006 by Java FAQs Daily Tips.

Interactive software released under GNU GPL, Code Credits, Privacy Policy