sp; public void run() {
scnFld.setText(sec.toString());
}
});
}
由于dispatcher既知道model激发的事件又知道事件本身－例如，它知道关联的modelKey和propertyKey－这是唯一需要用来绑定views和models的信息。Model和view甚至不需要分享通信接口或者共用的数据库。
借助我们讨论的绑定机制，我们可以轻易的改变潜在的view而不改变其他任何东西。下面的代码是按照使用SWT(Standard Widget Toolkit)而不是Swing实现的同一个method：
@ModelDependent(modelKey = "timeModel", propertyKey = "seconds")
public void setScnFld(final Integer sec){
Display.getDefault().asyncExec(new Runnable() {
public void run() {
secondsField.setText(sec.toString());
}
});
}
一个完全没有耦合的系统存在以下优点：View可以更加容易地适应model地改变，尽管model通常都是稳定地，相反view是经常被改变。加上系统可以通过使用GUI编辑器或者其他源码生成器来设计，避免了将生成地代码与model－view通信代码混合在一起。又由于model－view的绑定信息是和源码关联的元数据，于是也相对容易把它应用到IDE生成的GUIs或者将已经存在的应用程序转化成这个框架。加之拥有单独的基础代码，view和model可以被当作是独立组件来开发，这很可能简化了应用程序的开发过程。组件测试也可以被简化，因为每个组件可以被单独地测试，并且出于调试的目的，我们可以用假的model和view来代替真实的组件。
然而，这里也存在许多缺点。因为现在当使用接口和公共的classes来绑定model和view时，我们不能再提供编译时期的安全性了，可能出现的打字错误将导致组件之间一个绑定的遗漏，从而导致出现运行时期的错误。
通过使用@ModelDependent的讨论过的modelKey和propertyKey元素，你可以定义model和view之间静态的联系。然而，现实世界的应用程序证明view必须能够经常动态的适应变化的models和应用程序的状态：考虑到用户界面的不同部分能够在应用程序的生命周期内被创造和删除。因此我将介绍怎么使用这个框架与其他常用技术一起来处理此类情形。
动态MVC绑定
对于那些依赖XML绑定(或者其他一些基于配置文件的声明性绑定)的框架，存在一个问题那就是静态绑定规则。在这些框架下，动态变化是不可能的，于是通常开发者决定每次将冗余的绑定信息与一些使用正确绑定的判定算法耦合在一起。
为了巧妙的解决这个问题，Stamps框架提供了两种方式在运行时期改变绑定。 第一种方式是，views和models可以采用事件监听器与GUI窗口小部件联合的方式在dispatcher上注册和注销。这样允许特定的views只在需要他们的时候被通知到。例如，一个与应用程序有联系的监视控制台可以只在用户请求的时候与被它监视的对象绑定在一起。
第二种方式是利用@ModelDependent annotation提供的两个元素runtimeModel() 和 runtimeProperty()。他们指明了某个确定的model和它的分配事件会在运行时期被确定。如果这两个设定中有一个是正确的，那么各自的key(modelKey 或propertyKey)会在view上被method调用来得到需要使用的值。例如：一个负责显示一组新channels (每个channel就是一个model)的view，它就依赖于用户的输入来确定需要绑定的channel。
这种情形的实例如下：
// This method is invoked to display all the messages of one news channel
@ModelDependent(modelKey = "dynamicChannel", propertyKey = "allmessages" , runtimeModel = true)
public void setAllMessages(java.util.List messages) {
// Updates the user interface
}
public String getDynamicChannel() {
// Returns the channel requested by the user
}
附加的annotations
由于世界并不完美，一些附加的annotations被定义来帮助解决现实世界的案例。@Namespace允许开发者为了更好的管理model domain将其再细分成不同的部分。由于单独一个dispatcher可以处理多个models，model keys中将出现的冲突。因此，它能将成群的models和相关的views分到不同的但同属一个namespace下的domains中去, 这样一来，他们就不会干扰对方。
@Transform annotation提供了on-the-fly对象转化, 从包含在model事件中的对象到被receiving views接受的对象的。因而，这个框架就可以适应已存的代码而不需要做任何的改动。这个annotation接受一个注册在有效转化上的单一参数(被定义成一个特殊接口的实现)。
@Refreshable annotation能通过标注model的属性来支持前面讨论的动态连接和分离views。使用这个annotation，该框架可以处理静态和动态的MVC布局，在不同的时间把不同的views绑定到model上。
要理解@Refreshable的使用，我们必须回到之前的那个监控控制台的例子。这个控制台(用MVC的术语来说就是一个view)可以动态地绑定和离开model，取决于用户的需要
上一页 [1] [2] [3] [4] [5] 下一页
|
