看了
caoxg
在廣州
Bea User Group
上講的《利用元數據和
RIA
簡化企業應用程序的開發》的
PPT
，很有感觸，說說自己對于其中幾點的做法：
1
、構件化界面開發
??
對于構件化界面開發，必然是發展的趨勢，但覺得就目前的技術形式來看，我還是很同意
Tapestry
、
JSF
這些在服務器端進行界面建構的方式，這也是自己在現在的實際項目中采用的方式，盡管我也認為
XUL
會是一個良好的發展，畢竟界面確實不應該在服務器端組裝，個人覺得這里面最重要的一個原因在于現在從
UI Design
到
html
的生成比較簡單，而對于其他方式只能是由程序員自己去完成集成了，在
N
多實際項目中都體現出這個往往是項目最為耗時的部分，自己現在在這塊上還是傾向在服務器端通過
velocity
之類的模板機制來把
html
生成的方式，這樣既能發揮
ui design
到
html
生成的優勢，同時也避免界面集成過度復雜的方式。
???
另外，現在也在努力做采用附加的
xml
去直接描述
ui design
生成的
html
，理論上來講，這種方式就可以減少
UI
集成這塊的工作，其實就是依據目前的
UI Design
的工具來看，還是認為最好是保持
html
的純潔性，這樣
UI
集成的問題一定程度上是可以得到解決的，通過附加的
xml
去描述
html
中的動態元素。
???
象
zk
這樣的東西覺得現在不夠成熟或者說至少自己不會采用的原因就在于它仍然是要進行
UI
集成的，而這步仍然是要耗費很大的精力。
???
對
Qooxdoo
不熟悉，無法評價，不過既然是
javascript DHtml
的控件封裝的話，一定程度上倒是可以考慮考慮，在使用后再進行這部分的評價。
2
、是否需要在客戶端了解
property
的屬性
??
這點我覺得是肯定的，就像
PPT
上所說的一樣，
Validation
、
Query
這些是需要的，目前在實際中碰到的最重要的是在維護的時候需要，維護的時候通常都需要知道這個
POJO
的
property
的屬性的。
3
、是否需要在客戶端了解
POJO
之間的關聯關系
??
這點上覺得同樣是肯定的，頁面上有很多聯動性質的元素，這點在我目前的設計中我稱為是
link
方式的交互，這個要么是用戶自行定義要么是通過
POJO
之間的關聯關系自動形成。
??
另外在維護的時候這點同樣是至關重要的，至少在我目前設計的系統中維護的時候是非常需要知道
POJO
中
property
是否帶有關聯性質的。
4
、
Data Bind
??
這點無疑
ms
提供了不錯的示范，同時象現在
bstek
提供的東西，也是不錯的，很好的給予了數據綁定到客戶端控件的示例。
??
目前自己的做法和通常的做法也都差不多，控件上直接綁定查詢語句或是
xml
數據文件的方式。
?? Bind
后客戶端重新渲染的這個問題，我現在的做法就是我上面說的，在服務器端結合
Velocity
模板來完成這步的工作，之后把
html
返回給前端
js
，由其負責放至相應的容器
(span
、
div
等
)
中進行顯示。
??
關聯類型的綁定上現在我采用的是通過
js
綁定行為至控件上的方式
..
?? Metadata
確實是
Data Bind
的最重要來源，因為通常來說
Data Bind
做的目的還有很多其他的東西，象
Data
的維護、分頁、查詢等等，在我現在做的項目中分為了四個部分，分別是綁定的數據集元數據、顯示的元數據
(
包括
css
、
html
等
)
、字段的元數據
(
字段名、字段排序等
)
、操作的元數據
(
如分頁、新增等
)
，通過綁定的數據集元數據結合
Hibernate Metadata
形成數據方面的元數據信息，同時獲取到其中的關聯信息。
?
應該說，現在在
AJAX
開發這塊確實還有非常多需要改進的地方，
Data Bind
這塊其實一直是
java
界的一個弱點，覺得這其實也是為什么象
bstek
等等的東西可以得到應用場景的原因。
Data Bind
方面我覺得主要就是兩部分，一方面當然是
Data
，另一方面就是
metadata
，對于
metadata
的定義決定了其適用性，在這里拋磚引玉，說說自己現在的實際做法。
首先大概的說說我在
Data Bind
這塊的期望，我希望的是用戶可通過定義的方式來完成數據集組件的開發工作，這里所說的數據集組件大可以到一個用戶管理的模塊，小可以到一個用戶下拉列表，當然，其實這完全是可以通過定義方式的不同來決定的。
就假設數據集組件就是為了去支持一個用戶管理模塊的定義，這個時候其實可以想像如果要支持更為簡單的用戶下拉列表，當然是毫無問題的一件事，對一個通常的用戶管理模塊進行分析，我認為數據集組件中需要至少提供：
1、?
綁定數據集到數據集組件
對于數據集組件而言，無疑最重要的就是其所綁定的數據集是什么，通常來說可以是一個查詢語句或者是一個
xml
數據文件等。
2、?
設定數據集組件的顯示方式
這點我指的其實是需要控制數據集組件以表格方式展現或樹的方式展現等等，當然，象表格方式可能又會有多種，例如單選表格、多選表格等等。
還有就是象控制數據集組件的顯示形式方面，這點在我現在的設計中我采用的是保持
html
純潔性的原則，保持
web
界面的結構、顯示和行為三部分，期望開發人員可通過僅僅通過
css
定義來改變客戶端控件的顯示方式，而不是別的方式，客戶端控件中定義好的是結構。
3、?
設置數據集組件的字段映射
這點為什么需要的原因就在于通過綁定的數據集我們能獲取到的通常是數據表的
metadata
或
po
的
metadata
，但在具體做顯示的時候我們通常都需要采用有意義的文字來顯示字段，如用戶名對應著
po
中的
username
，同時還需要定義象字段的顯示順序等。
4、?
設置數據集組件的操作
這點指的就是為了滿足當一個數據集組件復雜到作為一個功能模塊的時候，例如有新增用戶、編輯用戶等，這個時候通過此部分的配置來決定當前的數據集組件是否擁有這些功能操作，同時定義這些功能操作中需要的元數據信息，如分頁操作需要的元數據信息就會有每頁記錄數等
…..
5、?
設置數據集組件的交互方式
這點是根據對于模塊頁面的交互來形成，例如在新增用戶的時候通常希望可以通過下拉或彈出等方式選擇用戶所屬的部門，又例如在一種主從關系的結構中通常需要在點擊主表的時候更新子表中的相應內容，感覺這樣說可能不太清楚，一個形象的例子其實還有就是在選擇了部門后，我們希望部門負責人這個下拉列表中相應的就只顯示該部門的負責人，根據這樣的分析，我把交互方式定義為了
link
、
dropdown
以及
popup
三種，而每種交互方式中又可以綁定一個數據集組件，也就是把三種交互方式都只是作為一種交互的容器而已，容器中仍然是放置數據集組件，在這樣的做法下，如我們要定義新增用戶的時候的所屬部門的字段可下拉選擇部門，這個時候我們可通過定義一個交互組件，這個交互組件為下拉交互組件，它綁定了一個部門列表的數據集組件，這個數據集組件綁定了一個查詢部門的語句，其顯示方式為單選表格，其操作方式為分頁操作，其需要顯示的字段為
Org.name
，相應的顯示出來的為組織機構名稱，在完成這些定義后我們可以將這個交互組件綁定到用戶管理數據集組件的所屬部門的字段上，通過這樣的方式后在新增、編輯用戶的時候就可看到所屬部門是可通過下拉列表進行選擇的。同樣，其他的交互方式也分別是采用類似的方式進行完成。
目前來說主要是通過了這五種元數據來形成整個數據集組件的定義，同時有一個專門的交互組件的定義，在擁有了這些元數據后通過
js
來實現數據集組件的行為，而這些
js
有純粹的客戶端的操作，也有與服務器交互的部分，根據這些元數據通過相應的客戶端控制來形成
html
，并將數據進行填充，根據這些元數據來控制頁面的顯示形式，在這點上我現在采用的就僅僅是
css
。
應該說上面所說的只是為了實現數據集組件的元數據定義，并不是說一定要基于
ajax
去實現，也可以通過別的方式去實現，目前我采用的是基于
dwr
，對于
web
界面就象我說的，我分為三部分：
1、?
html
在后臺通過
velocity
模板的方式來完成顯示，這個主要是由客戶端控件結合數據以及元數據來完成。
2、?
js
有前端的交互邏輯和與服務器的交互，當然，它也是要結合元數據的，這個在
dwr
、
buffalo
這些提供
java object
透明轉化
javascript object
支持的框架中就很好辦了。
在寫這塊的時候還是碰到不少的問題，目前覺得還是在事件機制上，現在自己也是寫了個基本的事件管理器，來實現基本的事件注冊、事件攔截器的注冊、事件的調用以及事件攔截器的有效范圍的控制。
3、?
css
控制數據集組件、交互組件的顯示方式，當然，這在一定程度上提高了對于
css
的要求。
改天截張現在做到的效果圖貼上來給大家看看，呵呵，其實我覺得也就是和
bstek
的東西差不多而已，只是某些方面稍有超越，
^_^
?
在基于一個這樣的東西上，開發人員可通過數據集組件、交互組件的配置來完成數據集組件、交互組件的開發工作，當然，在這樣的情況下，開發客戶端控件并不是一件什么很容易的事，因為既要了解元數據模型，又要了解數據部分的模型，還要完成客戶端控件的交互的實現
…..
開發人員在定義好了數據集組件后則只需要在需要顯示的頁面上使用
javascript
加載這個數據集組件就
OK
了，在這樣的方式一定程度上簡化了以前的
UI
集成工作，因為只需要將
UI Design
中需要轉化為動態的部分直接切換為數據集組件就可以了，而其他的
UI
部分的設計就可以不用去管了
..
下一步我就是希望通過一個附加的
xml
直接去描述
UI Design
形成的
html
，這樣的話即使
UI Design
的
html
改變了系統也是可以不改變的，一種可以想像的結果就是可以給用戶換一套
UI
，但后臺完全不需要做改變，
^_^
拋磚引玉，歡迎大家發表自己的看法，來交流交流，呵呵
….