也论基于元数据和RIA进行企业应用开发
看了 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 ，但后台完全不需要做改变， ^_^
抛砖引玉，欢迎大家发表自己的看法，来交流交流，呵呵 ….