Java平臺已經(jīng)逐漸發(fā)展為一個成熟可靠的企業(yè)應用平臺，成熟的應用平臺的一個標志則是它能夠帶動大量的衍生技術(shù)以及可以與其他技術(shù)集成的選 項。本文將詳細講述怎樣用Grails這項傳統(tǒng)JEE應用開發(fā)的衍生技術(shù)，結(jié)合另一項完全不同但卻可以在Java中使用的Flex技術(shù)來開發(fā)JEE。這兩 個平臺都能大幅度提高開發(fā)效率。兩者相結(jié)合則在為J2EE應用創(chuàng)建富客戶端的同時不影響整體的開發(fā)效率。

　　Grails的前身是一個在 JVM中運行的web應用，它使用Groovy以及其它幾個著名的框架，比如Spring和Hibernate。為了實現(xiàn)快速應用開發(fā)，它極為依賴 “Convention over Configuration”原則。Groovy擁有很多動態(tài)的特性，在定義組件間共同行為方面，功能非常強大。Grails采用plug-in構(gòu)架，因 此很容易把它與其他框架集成，而且也很容易在應用間復用各自的功能。

　　Flex是個RIA開發(fā)套件，由它創(chuàng)建的SWF應用只能在 FlashPlayer下應用。這是Adobe（前身為MacroMedia）的一個新型 Flash開發(fā)套件。除了擁有豐富的widget和把各種widget粘合在一起的強大的語言之外，它還能提供一些高端通信解決方案，分布式應用程序的開 發(fā)因此變得相當容易。它使用兩種語法：MXML和ActionScript。MXML創(chuàng)建在XML語法之上，專門用來定義通用組件的用戶接口；而 ActionScript則用來定義組件之間的動態(tài)交互。

　　Grails和Flex的集成——難題所在

　　要把Grails和Flex這兩個建立在完全不同基礎上的框架結(jié)合起來，首先會遇到諸多通信方面的問題：

　　一個框架中的組件如何才能在另一個框架中找到正確的通信對象？

 從本質(zhì)上來說，Grails實際是運行在服務器的JVM上的一個web應用框架。Flex則是擁有客戶端和（瘦）服務器組件的RIA平臺，服務器組件以web應用的方式部署。因此，這兩個框架之間的集成實際上在web應用容器內(nèi)進行。

　　用戶在Flex UI發(fā)起的通信必須通過Grails組件來調(diào)用業(yè)務邏輯。那么，F(xiàn)lex UI組件該如何找到正確的Grails組件呢？

　　框架間如何解析彼此的數(shù)據(jù)？

　　Flex采用ActionScript來描述數(shù)據(jù)，而Grails則采用Java和Groovy對象。Flex UI向服務器發(fā)送的ActionScript對象應該被轉(zhuǎn)述為應用程序能夠理解的數(shù)據(jù)結(jié)構(gòu)。這該如何實現(xiàn)？

　　某個用戶的修改該如何與該應用程序的其他用戶交互？

　　這是多用戶應用程序普遍存在的問題，但同時運用兩個不同的框架使得問題更加復雜。難點在于Grails應用程序，用戶通過Flex UI來啟動這個應用，但如何通過Flex UI與其他用戶通信，讓他們知道該用戶的這一動作呢？

　　在接下來的三個部分中，我們詳細討論上文提到的三個問題，尋找采用Grails和Flex的解決方案。

　　集成——尋找消息接收對象

　　一個框架中的組件如何才能在另一個框架中找到正確的通信對象呢？

　　具體到Grails和Flex的話，這個問題其實就是在問Flex組件怎樣才能找到正確的Grails組件，進而發(fā)送請求數(shù)據(jù)，或者以用戶的名義執(zhí)行一些操作。為了更好的理解解決這個難點的方法，我們首先來了解一下Flex的通信子系統(tǒng)。

　　Flex中的客戶——服務器通信

　 　Flex的通信子系統(tǒng)可以分為客戶和服務器兩個部分。客戶部分包含了那些允許應用程序發(fā)送或者接受消息的組件，比如RemoteObject和 Consumer組件。這些組件與服務器部分特定的“服務”對象相關聯(lián)，比如RemotingService和MessagingService。客戶組 件及其相關聯(lián)的服務器組件的結(jié)合能夠支持典型的通信模式。比方說結(jié)合Consumer、Producers和MessagingService，應用軟件 就能夠使用Publish-Subscribe機制來通信。

　　客戶和服務器件的通信通過信道（Channel）來完成。信道的實現(xiàn)方式并不唯一，所有信道中最重要的是AMFChannel和 RTMPChannel。 AMFChannel建立在HTTP基礎上，也就是說建立在請求－回復的構(gòu)架上。它可以和MessagingService同時使用，從而支持 Publish-Subscribe構(gòu)架。這種結(jié)合下，信道定期從發(fā)布中讀取新的消息，生成請求。RTMPChannel在這樣的配置下效率更高，它能夠 在TCP/IP的基礎上支持客戶與服務器間的連接。這樣一來，客戶與服務器之間能夠立即發(fā)送或接受消息。遺憾的是，Adobe免費開源的Flex實現(xiàn)—— BlazeDS不包含這樣的RTMPChannel實現(xiàn)。

　　Flex中最重要的通信基礎設施是Destinations。 Destination是通信信道的服務器端終點。一個服務提供一個 Destination，而客戶組件則通過這個Destination與這個服務相關聯(lián)。關聯(lián)的客戶組件可以向Destination發(fā)送和讀取消息。 Destinations可以由Factories創(chuàng)建。

　　Grails暴露的遠程接口：服務

　　如何把Flex復雜的 通信設施和Grails結(jié)合起來呢？Grails能夠識別幾類對象：域?qū)ο蟆⒖刂破鳌⒁晥D和服務。Grails中的每個服務都是通過外部通信信道——比如 HTTP——展示某些功能或者服務的一個對象。而在Flex中，每個服務則與一個Destination相對應。

　　這恰恰就是針對 Grails的flex-plugin所提供的解決方案。Grails中所有注明向Flex展示的服務都將在Flex框架中以Destination的形 式注冊。Grails通過一個特定的 Factory把注明的服務添加到Flex中特別配置的RemotingService。這個特定的Factory會在Grails使用的Spring上 下文中定位到對應的服務。所有這些配置都可以在services-config.xml中找到，flex-plugin會為Grails將這個文件復制到 正確的地方。

class UserService {
static expose = ['flex-remoting']
def List all() {
User.createCriteria().listDistinct {}
}
def Object get(id) {
User.get(id);
}
def List update(User entity) throws BindException {
entity.merge();
if (entity.errors.hasErrors()) {
throw new BindException(entity.errors);
}
all();
}
def List remove(User entity) {
entity.delete();
all();
}
}

　 　這段配置將UserService展示給flex客戶。下面這段MXML代碼則是對前面這段配置的應用。RemoteObject的 destination是userService，這個userService正是Grails中目標對象提供的服務名。服務對象的所有方法這下都可以作 為遠程操作調(diào)用。ActionScript可以將這些操作像一般的方法那樣調(diào)用，而方法調(diào)用的結(jié)果或錯誤也可以當作一般的ActionScript事件來 處理。

...
<mx:RemoteObject id="service" destination="userService">
<mx:operation name="all" result="setList(event.message.body)"/>
<mx:operation name="get" result="setSelected(event.message.body)"/>
<mx:operation name="update"/>
<mx:operation name="remove"/>
</mx:RemoteObject>
...結(jié)論

　　flex-plugin為Grails提供的針對集成的解決方案非常漂亮，易于使用而且?guī)缀跏亲詣踊摹Ｔ贑onvention-over-Configuration概念下，Destinations動態(tài)添加到Flex配置的時候使用命名規(guī)范。

　　數(shù)據(jù)轉(zhuǎn)換

　　框架間如何互相轉(zhuǎn)換對方的數(shù)據(jù)（本文中就是Java和ActionScript對象轉(zhuǎn)換的問題）？

　　這個問題的關鍵之處在于兩框架相交接的地方。Flex包含Java（web服務器）和ActionScript（客戶端）兩個組件。因此，Grails和Flex之間的邊界就在web服務器，而這個服務器在兩個框架內(nèi)實際上都是Java應用。

　　Flex的Java組件只關注于與Flex客戶間的通信。基于ActionScript對象的AMF協(xié)議就用于這樣的數(shù)據(jù)通信。服務器內(nèi)部的 Java代碼將數(shù)據(jù)轉(zhuǎn)換成ActionScript對象，這些對象在信道上實現(xiàn)系列化。Flex支持Java的基本類型，也支持其標準復雜類型（比如 Date或者 Collection類型）。由于ActionScript是門動態(tài)語言，因此它也支持隨機對象結(jié)構(gòu)。Java對象域會轉(zhuǎn)換成ActionScript對 象的動態(tài)屬性。但把這些非類型ActionScript對象轉(zhuǎn)換成Groovy域?qū)ο蟮倪^程則沒那么直接，它會默認生成一個Map，將屬性以key- Value對的形式存儲到這個Map中。

　　Flex創(chuàng)建與Groovy域?qū)ο髶碛型瑯訉傩缘腁ctionScript類，通過注解將兩者互相關聯(lián)起來，這樣一來，數(shù)據(jù)轉(zhuǎn)換更加方便。下面的這個例子就是這樣一對關聯(lián)的Groovy-ActionScript。

注 解“RemoteClass”將ActionScript類鏈接到由alias屬性指明的Java(或Groovy)類。alias這個屬性應該包含完整 的類名。Grails中的領域類通常都添加到默認的類包。Grails類中的所有屬性都會復制到ActionScript類。這些屬性的名字都應當完全一 樣。Grails會為所有需要“id”和“version”的領域?qū)ο髣討B(tài)添加這兩個屬性，領域?qū)ο笠虼丝梢栽谂c客戶端交互的時候保留這兩個信息。
結(jié)論
Flex 提供的與Java（或Groovy）間數(shù)據(jù)轉(zhuǎn)換的解決方案會導致很多重復的代碼。每個領域類都會被定義兩次，一次用Groovy（或Java）定義，另一 次用ActionScript。但是這樣一來，可以添加一些客戶端特定代碼，比如說那些單單用ActionScript編寫的控制對象顯示的代碼。這也推 動編輯器同時提供兩種代碼的自動完成功能。至于用于配置的注解則非常簡便。
多用戶
應用程序如何將某個用戶所作的修改通知到其他用戶？
對于一個能同時支持多用戶的應用程序來說，將某個用戶對共享數(shù)據(jù)所做的修改通知到其他用戶著實是個挑戰(zhàn)。對于其他用戶來說，這個過程可以看作是有服務器發(fā)起的通信。
單個中央結(jié)點（通常指服務器）向很多接收點（通常指客戶）發(fā)起通信的時候，發(fā)布－注冊（publish-subscribe）就非常實用。客戶在服務器上注冊之后，服務器上任何相關消息的發(fā)布，他們都會收到通知。
由于Grails可以使用Java，自然就可以用到JMS。JMS是應用程序間通信的Java標準，它支持publish-subscribe技術(shù)，而且應用程序也可以通過適配器來集成JMS。
Grails中的JMS配置
在眾多標準中，有一個特別針對Grails的jms-plugin，它添加了很多有用的方法可以用來向JMS目的地對象、向所有的控制器和服務類發(fā)送消息。在上一章中提到的UserService就可以運用這些方法在數(shù)據(jù)發(fā)生變化時通過JMS向所有的用戶發(fā)送更新消息。
class UserService {
...
def List update(User entity) throws　BindException {
entity.merge(flush:true );
if　(entity.errors.hasErrors()) {
throw new BindException(entity.errors)
}
sendUpdate();
all();
}
def List remove(User entity) {
entity.delete(flush:true );
sendUpdate();
all();
}
private def void sendUpdate() {
try　{
sendPubSubJMSMessage("tpc",all(),[type:"User"]);
} catch (Exception e) {
log.error("Sending updates failed.", e);
}
}
}

　 　服務可以決定什么時候發(fā)送什么樣的消息。無論用戶什么時候更新或刪除數(shù)據(jù)，都會發(fā)送一條包含了完整的數(shù)據(jù)列表的消息。這條消息會發(fā)送到特定話題，也就是 這里的“tpc”。任何注冊了這個話題的用戶都將接收到新數(shù)據(jù)。列表中的對象類型（本例中也就是“User”）作為元數(shù)據(jù)添加到消息中，接收對象因此在服 務器上注冊的時候特別指明他們所關注的數(shù)據(jù)類型。

　　為了讓Grails應用也能夠采用JMS，每個JMS都需要實現(xiàn)provider。 Apache有個免費的開源實現(xiàn)，只需簡單配置就能在Grails應用程序中使用。你所需要做的是把ApacheMQ類庫添加到Grails應用的lib 文件夾下，再將下列代碼段復制到connection factory所使用的conf/spring文件夾下的resources.xml中。

...
<bean id="connectionFactory"
class="org.apache.activemq.pool.PooledConnectionFactory"
destroy-method="stop">
<property name="connectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="vm://localhost"/>
</bean>
</property>
</bean>
...在Flex中接收JMS消息

　 　目前的Flex配置僅僅包含一個RemotingService，依靠它來支持request-response類型的用戶與UserService間 交互。這個服務由flex-plugin向Grails中添加。除此之外，我們還需要一個MessagingService來支持publish- subscribe類型的交互。

...
<service id="message-service" class="flex.messaging.services.MessageService" messageTypes="flex.messaging.messages.AsyncMessage">
<adapters>
<adapter-definition id="jms" class="flex.messaging.services.messaging.adapters.JMSAdapter" default="true"/>　　　 </adapters>　　　　<destination id="tpc">
<properties>
<jms>
<message-type>javax.jms.ObjectMessage</message-type>
<connection-factory>ConnectionFactory</connection-factory>
<destination-jndi-name>tpc</destination-jndi-name>
<delivery-mode>NON_PERSISTENT</delivery-mode>
<message-priority>DEFAULT_PRIORITY</message-priority>
<acknowledge-mode>AUTO_ACKNOWLEDGE</acknowledge-mode>
<transacted-sessions>false</transacted-sessions>
<initial-context-environment>
<property>
<name>Context.PROVIDER_URL</name>
<value>vm://localhost</value>
</property>
<property>
<name>Context.INITIAL_CONTEXT_FACTORY</name>
<value>org.apache.activemq.jndi.ActiveMQInitialContextFactory</value>
</property>
<property>
<name>topic.tpc</name>
<value>tpc</value>
</property>
</initial-context-environment>
</jms>
</properties>
</destination>
</service>
...

　 　在services-config.xml文件中，我們需要添加下列這段包含了一個新的MessagingService和JMSAdapter的代碼 段。添加的這個適配器將服務中的destination鏈接到JMS資源。這個服務中還包含一個destination的配置，flex代碼中的用戶可以 通過注冊獲得這個destination的數(shù)據(jù)更新。Destination中含有很多JMS特定的配置。大部分都是常用的JMS屬性。initial- context-environment中的“topic.tpc”屬性是個可定制的ActiveMQ屬性，這個屬性將在上下文中注冊一個JNDI名為 “tpc”的話題。

...
<mx:Consumer destination="tpc" selector="type = 'User'"
message="setList(event.message.body)"/>
...

　 　Flex客戶端代碼非常簡單。消息根據(jù)選擇器（selector）被發(fā)送到特定的destination，而Consumer組件因此接受到所對應的 destination中的消息。在這個例子中，我們通過篩選器指定Consumer所關注的消息是元數(shù)據(jù)“type”屬性值為“User”的內(nèi)容。無論 消息是何時收到的，消息的內(nèi)容，也就是User-objects列表會被置為可顯示的內(nèi)部列表。消息內(nèi)容的處理和RemoteObject上“all”處 理的返回值完全一樣。

　　結(jié)論

　　Grails和Flex中將數(shù)據(jù)變化傳遞給多用戶的解決方案完全可以通過標準組件來實現(xiàn)。涉及到的組件數(shù)量很多，配置和實現(xiàn)因此相當復雜。如果配置正確的話，這個解決方案使用起來就非常方便。

　　合并解決方案

　　回顧前三章提出的解決方案，你會發(fā)現(xiàn)還可以把他們合并起來得到一個更為通用的解決方案來實現(xiàn)Flex/Grails應用程序客戶與服務器間的關于領域狀態(tài)信息的通信。本章節(jié)中，我們要討論的就是這樣一個更為通用的解決方案。

　　泛化服務器端代碼

　　問題1和3的解決方案所需要的服務器端的代碼可以合并到同一個Groovy服務中。我們將把它指明為針對User領域類的服務。通過Groovy這樣一門動態(tài)語言，要把這樣一個服務泛化到面向所有領域類的操作非常容易。

import org.codehaus.groovy.grails.commons.ApplicationHolder
class CrudService {
static expose = ['flex-remoting']
def List all(String domainType) {
clazz(domainType).createCriteria().listDistinct {}
}
def Object get(String domainType, id) {
clazz(domainType).get(id)
}
def List update(String domainType, Object entity)
throws BindException {
entity.merge(deepValidate:false, flush:true)
if (entity.errors.hasErrors()) {
throw new BindException(entity.errors)
}
sendUpdate(domainType);
all(domainType);
}
def List remove(String domainType, Object entity) {
entity.delete(flush:true);
sendUpdate(domainType);
all(domainType);
}
private def Class clazz(className) {
return ApplicationHolder.application.getClassForName(className);
}
private def void sendUpdate(String domainType) {
try {
sendPubSubJMSMessage("tpc", all(domainType), [type:domainType]);
} catch (Exception e) {
log.error("Sending updates failed.", e);
}
}
}

　 　要實現(xiàn)這個目的的關鍵在于讓客戶來決定返回的領域類型。出于這個目的，我們需要為所有服務引入一個參數(shù)，通過這個參數(shù)為服務器鑒定各個領域類型。很明 顯，對于這個參數(shù)來說，領域類型的類名是無非是最好的選擇。為所有領域?qū)ο筇峁?C(reate)R(etrieve)U(pdate)D(elete)操 作的服務被稱為CrudService。

　　一旦有任何數(shù)據(jù)更改，CrudService都會向JMS話題發(fā)送更新消息。這個更新消息包含了應用程序所知道的完整的領域?qū)ο罅斜怼榱俗層?戶來決定這是否是自己心儀的更新內(nèi)容，領域類型的類名將以元數(shù)據(jù)方式添加到消息中。

　　客戶端代碼

 解決方案1和3中的客戶端ActionScript代碼也可以綜合到同一個類中。這個類的實例可以用來管理客戶端某個特定領域類型的所有實例集。

public class DomainInstancesManager
{
private var domainType : String;
public function EntityManager(domainType : String, destination : String) {
this.domainType = domainType;
initializeRemoteObject();
initializeConsumer(destination);
}
private var　_list : ArrayCollection = new ArrayCollection();
public function get list () : ArrayCollection {
return _list;
}
private function setList(list : *) : void {
_list.removeAll();
for each (var o : * in list) {
_list.addItem(o);
}
}
internal static function defaultFault(error : FaultEvent) : void {
Alert.show("Error while communicating with server: " + error.fault.faultString);
}
...
}

　 　實現(xiàn)客戶端的ActionScript基本上包含兩個組件：簡化request-response對話的RemoteObject和用于 producer-subscriber對話的Consumer組件。上一章節(jié)中，這些對象通過MXML代碼實現(xiàn)初始化，但他們也可以通過 ActionScript來創(chuàng)建。上面這段代碼段顯示的是這兩個組件共同使用的結(jié)構(gòu)：包含了實例和錯誤處理的列表。包含實例的列表根據(jù)任何一個通信組件發(fā) 送的消息而更新。

　...
private var consumer : Consumer;
private function initializeConsumer(destination : String) : void {
this.consumer = new Consumer();
this.consumer.destination = destination;
this.consumer.selector = "type ='" + domainType + "'";
this.consumer.addEventListener(MessageEvent.MESSAGE, setListFromMessage);
this.consumer.subscribe();
}
private function setListFromMessage(e : MessageEvent) : void {
setList(e.message.body);
}
...

　 　這里這段代碼顯示的是Consumer如何通過ActionScript來構(gòu)建，這段代碼用來接收服務器端發(fā)送的消息。Consumer的 selector屬性僅僅用來接收那些包括了元數(shù)據(jù)中所指明的領域類型的消息。無論什么時候接收到這樣的消息，event handler都會被調(diào)用，并且列表也會得到更新。

　　接下來這段代碼段將RemoteObject設置為request-response型通信的一個結(jié)點。所有必要的操作都作為操作屬性而添加到RemoteObject上，客戶因而很容易調(diào)用這些操作。

...
private var service : RemoteObject;
private var getOperation : Operation = new Operation();
public function initializeRemoteObject() {
this.service = new RemoteObject("crudService");
var operations:Object = new　Object();
operations["all"] =　new　Operation();
operations["all"].addEventListener(ResultEvent.RESULT, setListFromInvocation);
operations["get"] = getOperation
operations["remove"] = new　Operation()
operations["remove"].addEventListener(ResultEvent.RESULT, setListFromInvocation);
operations["update"] = new　Operation()
operations["update"].addEventListener(ResultEvent.RESULT, setListFromInvocation);
this .service.operations = operations;
this .service.addEventListener(FaultEvent.FAULT, defaultFault);
// Get the instances from the server.
this.service.all(domainType);
}
public function get(id : *, callback : Function) : void {
var future: AsyncToken = getOperation.send(domainType, id);
future.addResponder(new CallbackResponder(callback));
}
public function update(entity : Object) : void {
service.update(domainType, entity);
}
public function remove(entity : Object) : void {
service.remove(domainType, entity);
}
private function setListFromInvocation(e : ResultEvent) : void {
setList(e.message.body);
}
...

　 　大部分方法都將任務委派到服務的其中一個操作。所有這些操作都不會阻塞其它操作，同時它們都是異步操作。服務的返回值無論什么時候都會由注冊的事件處理 器（eventhandler，本例中為setListFromInvocation）來處理，這個處理器同時還會更新列表。由于返回值在很多地方都會用 到，“getOperation”就顯得有點特別。CallbackResponder只有注冊了調(diào)用才能得到該調(diào)用的返回值。答復方也將調(diào)用一個 Function來處理剛接收到的消息的內(nèi)容。

import　mx.rpc.IResponder;
import　mx.rpc.events.ResultEvent;
public　class CallbackResponder implements　IResponder {
private　var callback : Function;
function CallbackResponder(callback : Function) {
this .callback = callback;
}
public　function result(data : Object) : void　{
callback(ResultEvent(data).message.body);
}
public　function fault(info : Object) : void　{
DomainInstancesManager.defaultFault(info);
}
}使用通用的類包

　 　怎樣使用這個通用的類包呢？我們來看一個例子，這個例子中我們要實現(xiàn)的是在第二個解決方案中提到的管理User對象的實例。下面這段MXML代碼定義了 一個PopUpDialog，這個PopUpDialog可以用來編輯系統(tǒng)中Users的詳細信息。這個對話框的外觀就如左圖所示。實例變量 “manager”為User領域類型初始為一個DomainInstanceManager實例。界面中包含了所有捆綁到這個manager的list 屬性的用戶的列表。它顯示了用戶的displayName值。

<mx:TitleWindow xmlns:mx="//www.adobe.com/2006/mxml" xmlns:users="users.*" title="User Manager">
<mx:Script>
<![CDATA[
import crud.DomainInstancesManager;
import mx.managers.PopUpManager;
[Bindable]
private var　manager : DomainInstancesManager = new DomainInstancesManager("User", "tpc");
private function resetForm() : void {
selectedUser = new User();
secondPasswordInput.text = "";
}
private function　setSelected(o : Object) : void
{
selectedUser = User(o);
secondPasswordInput.text = selectedUser.password;
}
]]>
</mx:Script>
<users:User id="selectedUser"
displayName="{displayNameInput.text}"
username="{usernameInput.text}"
password="{passwordInput.text}"/>
<mx:List height="100%" width="200" dataProvider="{manager.list}" labelField="displayName"
itemClick="manager.get(User(event.currentTarget.selectedItem).id, setSelected)"/>
<mx:VBox height="100%" horizontalAlign="right">
<mx:Form>
<mx:FormItem label="Display Name">
<mx:TextInput id="displayNameInput" text="{selectedUser.displayName}"/>
</mx:FormItem>
<mx:FormItem label="User Name">
<mx:TextInput id="usernameInput" text="{selectedUser.username}"/>
</mx:FormItem>
<mx:FormItem label="Password">
<mx:TextInput id="passwordInput" text="{selectedUser.password}" displayAsPassword="true"/>
</mx:FormItem>
<mx:FormItem label="Password">
<mx:TextInput id="secondPasswordInput" text="" displayAsPassword="true"/>
</mx:FormItem>
</mx:Form>
<mx:HBox width="100%">
<mx:Button label="New User" click="{resetForm()}"/>
<mx:Button label="Update User" click="{manager.update(selectedUser);resetForm()}"/>
<mx:Button label="Remove User" click="{manager.remove(selectedUser);resetForm()}"/>
</mx:HBox>
<mx:Button label="Close" click="PopUpManager.removePopUp(this)"/>
</mx:VBox>
</mx:TitleWindow>

　 　一旦點擊列表中的數(shù)據(jù)項，你就可以從服務端讀取對應的user對象的數(shù)據(jù)，這些數(shù)據(jù)存儲在界面的“ selectedUser”中。這個屬性在MXML中定義，因此很容易用來與表單中的域綁定。 “selectedUser”屬性的屬性和表單中的input域是雙向綁定，所以“selectedUser”屬性值的改變（由服務器端的事件引發(fā)的修 改）會影響到input域，而input域的值的改變（由用戶輸入值所引發(fā)的修改）也會影響到“selectedUser”屬性值。界面上的按鈕是鏈接到 manager的方法，這個方法的參數(shù)就是“selectedUser”屬性值。方法調(diào)用的結(jié)果會影響到manager維護的表單，也會影響到界面上顯示 的列表內(nèi)容，因為這兩者也是互相綁定的。

　　注意事項

　　需要注意的是，在使用這個通用類庫的時候，你需要在客戶端維護一個包含了系統(tǒng)所識別的某個特定類型的所有對象的列 表。有些你所期望使用的引用數(shù)據(jù)和數(shù)據(jù)本身可能會在實例的數(shù)量上有一定的限制，這沒什么問題。另外還有一些數(shù)據(jù)你可能不是必須的，甚至不可能維護一個完整 的列表，這時候你可以在這個完整的表單的子集上采用同樣的原理。

　　有趣的是，無論客戶何時修改數(shù)據(jù)（無論是保存、更新或是刪除領域?qū)?象），他都會得到一個包含了新的列表的回復。他還會接收到一個消息表明其他用戶也都收到了更新的列表。因此，用戶會因為自己的每個修改而收到兩條更新消 息。第一條（針對他請求的回復）可以被丟棄，但這條消息會添加到系統(tǒng)中，因為直接回復常常比通過JMS發(fā)送消息更費時間。

　　另外一個值得 提及的是，由于消息中包含的更新（本例中就是完整的列表）來自于不同的信道，這個模型中可能存在并發(fā)問題。消息有可能被延遲，用戶可能在收到一個更新消息 之后再收到收到上一個更新的消息。這也意味著用戶看到的是失去實效的數(shù)據(jù)。解決這個問題的一個方法是在消息中添加一個序列號，然后在每次接收消息的時候通 過檢驗這個序列號來查看這條信息是否是最新的。

　　結(jié)論

　　通用的類包以易于使用的形式包含了前面幾章中討論的解決方案。

　　本文中提到的解決方案能夠為開發(fā)使用Flex和Grails的JEE應用程序提供堅固的基礎。采用這個工具箱的JEE開發(fā)人員的開發(fā)將可以更快、更敏捷，也許更重要的是開發(fā)將變得更有趣！

　　關于作者

 Maarten Winkels是具有五年Java和JEE開發(fā)經(jīng)驗的軟件開發(fā)工程師和咨詢師。他最近從荷蘭搬遷到印度，宣傳Xebia所提供的分布式敏捷開發(fā)過程。 Xebia是一家專于Java技術(shù)、海外Agile項目、Agile咨詢和培訓、IT構(gòu)架和審核的公司。