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