仅仅通过观察这段代码，您就可以看出，映射文件清晰地勾划出了每个用来存储表模型信息的类，定义了类的类型，并将 XML 文件中的名称连接到了 Java 对象中的字段。请保持相同的名称，这样会让事情简单、更好管理一些，但是没必要保持名称相同。
到现在为止，列名和字段信息都已外部化，可以读入包含列信息的 Java 对象中，并且可以很容易地把信息发送给 BeanTableModel，并用它来设置列。
ObservableCollection
TMF 框架的最后一个关键部分，就是 ObservableCollection 。您们当中的某些人可能熟悉 ObservableCollection 的概念，它是 Java Collections 框架的一个成员，在被修改的时候，它会抛出事件，从而允许其侦听器根据这些事件执行操作。虽然从来没有将它引入 Java 语言的正式发行版中，但在 Internet 上，这个概念已经有了一些第三方实现。就本文而言，我使用了自己的 ObservableCollection 实现，因为框架只需要一些最基本的功能。我的实现使用了一个称为 collectionChanged() 的方法，每次发生修改时， ObservableCollection 都会在自己的侦听器上调用该方法。也可以将该用法称为 Collection 类的 Decorator(有关 Collections 的 Decorator 更多信息，请参阅 Collections 框架的站点)，只需要增加几行代码，您就可以在普通的 Collection 类中创建 Collection 类的 Observable 实例。清单 5 显示了 ObservableCollection 用法的示例。(这只是一个示例，没有包含在 j2x.zip 中。)
清单 5. ObservableCollection 用法示例
1 // convert a normal list to an ObservableList
2 ObservableList oList = CollectionUtilities.observableList(list);
3 // A listener could then register for events from this list by calling
4 oList.addCollectionListener(this);
5 // trigger event
6 oList.add(new Integer(3));
7 // listener receives event
8 public void collectionChanged(CollectionEvent e)
9 {
10 // event received here
11 }
12
ObservableCollection 有许多 TMF 框架之外的应用程序。如果您决定采用 TMF 框架，您会发现，在开发代码期间， ObservableCollection 框架有许多实际的用途。
但是，它在 TMF 框架中的用途，重点在于它能更好地定义视图和模型之间的关系，当数据发生变化时，可以自动更新视图。您可以回想一下，这正是传统 TableModel 的最大限制，因为每当数据发生变化时，都必须用表模型的引用来更新视图。而在 TMF 框架中使用 ObservableCollection 时，当数据发生变化时，视图会自动更新，不需要维护一个到模型的引用。在 BeanTableModel 的 collectionChanged() 方法的实现中，您可以看到这一点。
TableUtilities
在该框架中执行的最后一步操作，是将所有内容集成到一些实用方法中，让 TMF 框架使用起来简单明了。这些实用方法可以在 com.ibm.j2x.swing.table.TableUtilities 类中找到，该类提供了您将需要的所有辅助函数：
getColumnInfo() ：该实用方法用 Castor XML 文件解析指定的文件，并返回指定表模型的所有列信息，返回的形式是 BeanTableModel 所需的 LinkedMap 。当开发人员选择从 BeanTableModel 中派生子类时，这个方法很重要。
getTableModel() ：该实用方法是建立在上面的 getColumnInfo() 方法之上，它获得列的信息，然后把信息传递给 BeanTableModel，返回已经设置好所有信息的 BeanTableModel。
setViewToModel() ：该实用方法是最重要的函数，也是 TMF 框架的主要吸引人的地方。它也是建立在 getTableModel() 方法之上，也有一个到 JTable 的引用(JTable 中有这个表的模型)，以及一个到数据(要在表中显示)的引用。它对 JTable 上的 TableModel 进行设置，并把数据传递给 TableModel，结果是：只需一行代码，就为 JTable 完成了 TableModel 的设置。TMF 框架在该方法上得到了最佳印证，TableModel 将永远地被下面这个简单的方法所代替：
1 TableUtilities.setViewToModel("table_config.xml", "Table", myJTable, myList);
每篇关于 GUI 编程的文章都需要一个示例，本文当然也不例外。该示例的目的是指出使用 TMF 框架代替传统 TableModel 设计的主要优势所在。示例中的应用程序将在屏幕上显示多个表，并且可以添加或删除表，表中可以包含不同类型的信息( String 类型、 int 类型、 Boolean 类型和 BigDecimal 类型)，而且最重要的是，其中还包含可配置的列信息，必须定期更改它们。
示例应用程序的代码从 J2X 包中分离了出来，您可以 HR 文件夹的 src 目录中找到源代码。还可以双击 build/lib 文件中编译好的 JAR 文件，通过 JRE 运行应用程序。
在示例应用程序中，有两个类可以相互交换，一个叫作 TableModelFreeExample ，另一个叫作 TableModelExample 。这两个类在应用程序中做的是同样的事，使应用程序产生的行为也相同。但是，它们的设计不同，一个使用的是 TMF 框架，另外一个则使用传统的 TableModel。您从它们身上注意到的第一件事可能是 TMF 类 TableModelFreeExample ，该类由 63 行代码构成，而在传统 TableModel 版本 TableModelExample 中，它长达 285 行。
Evil HR Director 应用程序
我要使用的示例应用程序是 Evil HR Director 应用程序，它允许人力资源总监(可能很可怕，戴着眼镜)在 JTable 中查看潜在雇员的列表，然后从表中选出雇佣的人。新雇佣的员工的资料会转移到当前雇员使用的两个 JTable 中;其中一个表包含个人信息，另外一个表包含财务信息。在当前雇员表中，总监可以随意选择解雇谁。
Evil HR Director 应用程序
为了进一步证明 TMF 框架的简单性，请看清单 6。这个清单只包含三行必需的代码，就可以创建 Evil HR Director 应用程序中包含的三个表的模型。这些代码可以在 TableModelFreeExample 中找到。
清单 6.在 Evil HR Director 应用程序中创建模型所需要的代码
1 TableUtilities.setViewToModel("demo/hr/resources/evil_hr_table.xml",
2 "Hire", hireTable, candidates);
3 TableUtilities.setViewToModel("demo/hr/resources/evil_hr_table.xml",
4 "Personal", personalTable, employees);
5 TableUtilities.setViewToModel("demo/hr/resources/evil_hr_table.xml",
6 "Financial", financialTable, employees);
7
为了进行比较， TableModelExample 中包含用传统 TableModel 方法为三个表格创建模型所需要的代码。请查看示例包中的代码。不过，我不想在这里列出所有代码，因为它足足有 205 行!
演示 TMF 框架的灵活性
TMF 框架的巨大优势之一，是它能更加容易地基于 JTable 的应用程序在其发布之后进行修改。为了证实这一点，让我们来看两个可能的场景，这两个场景在使用 Evil HR Director 应用程序中每天都可能出现。在每个场景中，您都会看到框架是如何让应用程序更加容易地适应不断变化的用户需求。
场景 1：公司的策略发生变化，规定在公司的应用程序中查看私人的婚姻信息是非法的。
TMF：最终用户需要从 XML 配置文件中删除 Married?married 。
传统 TableModel：开发人员必须深入研究 Java 代码，修改 getColumnName() ，让它无法返回列名“Married?”;修改 getColumnCount() ，让它返回的结果比以前返回的结果少一列;修改 getValueAt() ，不让它返回 isMarried() 。然后开发人员必须重新编译 Java 代码，并重新部署应用程序。
场景 2：公司策略发生变化，公司觉得有必要在潜在雇员表中包含居住地所在的州的信息。
TMF：: 最终用户需要将 Statestate 添加到 XML 配置文件中。
传统 TableModel：开发人员必须深入研究 Java 代码，修改 getColumnName() ，添加一个叫作 “State” 新列;修改 getColumnCount() ，让它返回的列数加 1 ;修改 getValueAt() ，让它返回 getState() 。然后开发人员必须重新编译 Java 代码，并重新部署应用程序。
您可以看到，当应用程序中的表发生变化时(尤其在碰到一个总是朝令夕改的老板时，更改更加频繁)，编辑 XML 文件要比重新部署整个应用程序容易得多。
使用代码
在您飞奔过去删除所有 TableModel 代码之前，我想我还得占用您一分钟解释一下 j2x.zip 文件的内容，以及您怎样才能在您自己的项目中使用它。(请记住，特定于 TMF 的代码可以在 com.ibm.j2x.swing.table 包中找到;您还会在 J2X 包中找到我在以前的文章“Go state-of-the-art with IFrame.”中介绍的其他代码。)
j2x.zip 文件包含两上文件夹：
src—— 包含本文中使用的源代码。在 src 文件夹中，还有两个文件夹：一个是 HR，包含构成 Evil HR Director 应用程序的源代码;另一个是 J2X，包含 J2X 项目中使用的所有源代码。
build—— 包含 Evil HR Director 应用程序和 J2X 项目编译后的类文件。该文件夹中的 lib 文件夹则包含 HR 应用程序和 J2X 项目的 JAR 文件。
lib.zip 文件包含以下文件夹：
lib—— 包含所有的第三方 JAR 文件，运行应用程序或者任何使用 J2X 项目的项目，需要使用这些文件。在这个文件夹中，您还会找到第三方项目的许可。
docs.zip 文件包含下列文件夹：
docs—— 包含 J2X 项目的所有 JavaDoc 信息。
要在应用程序中使用 J2X 包，则需要把 CLASSPATH 指向 build/lib 文件夹中的 j2x.jar 以及 lib 文件中包含的所有三个第三方 JAR 文件。第三方包的许可条款允许您重新发布本文包含的所有包，但是如果有兴趣对这些包做些修改，请阅读许可条款。
结束语
使用 TableModel Free 框架，就不用再编写传统 TableModel 了。TMF 框架改进了 JTable 和 TableModel 模型之间的 MVC 关系，更清楚地分离了它们。在日后的发布中，您甚至可以在不修改任何模型代码的情况下，对组件进行热交换。框架还允许您在模型发生变化时，自动更新视图，从而消除传统 TableModel 设计中所必需的视图和模型之间的通信。
TMF 框架还会极大地减少开发 GUI 所需的时间，特别是在处理 JTable 时。几年以前，我处理的一个应用程序中有 150 多个 JTable，每个表都来自同一个原始表模型，该应用程序可以作为示例。使用 TMF 框架，我们只用 150 行代码就能解决问题;但是不幸的是，当时还没有 TMF，所以我们最后编写了 15,000 行额外的代码，才生成必需的表模型。这不但增加了开发时间，还增加了测试和调试的时间。
与使用传统 TableModel 相比，使用 TMF 框架使您到了一个更加容易配置所有 JTable 的时代。请想像这样一个 POS 应用程序：该应用程序被销售给了 5 个不同的客户，每个客户都有一套特定的信息，所以每个用户都想有一组显示在 GUI 上的特定的列。如果没有 TMF 框架，您就必须为每个客户都生成一组特定的 TableModel —— 由此，也就生成了一组特定的应用程序。而使用可配置的 XML 文件，每个客户都可以使用相同的应用程序，客户所在地的业务分析师可以根据需要修改 XML 文件。请想像一下，这节约了多少开发和支持成本!
TableModel Free 框架解决了 Swing 开发人员社区的特定需求：减少了处理 JTable 时的开发时间和维护开销，提高了它们对终端用户的易用性。Swing 桌面正在回归，使用像 TMF 框架这样的工具，开发人员会发现可以更容易地使用 Swing 和开发 GUI 应用程序。您要做的第一步就是用 TMF 框架的一行代码代替您所有的 TableModel，把所有 TableModel 都永远地抛到虚拟空间的黑洞中去吧。
上一页 [1] [2] [3]
责任编辑：小草
您现在的位置： 