一个基于 HTML 的 Rich Client 框架需要哪些内容？

1、一个结合后台组件的分页控件，实现方便的数据分页显示和翻页功能。
2、一个支持批量添加的控件，可以自动填入页面上很多不需要用户输入的字段，方便用户的输入。而且可以自动检查必输字段，还可以对用户输入的内容进行校验。
3、一个可以通过后台组件灵活配置的 Tree 控件，显示某种层次结构，例如组织机构目录树。
4、一个与 table 结合的 Grid 控件，可以将 table 的某一行、列隐藏/显示，也可以改变某一列的宽度。
5、一个对于数据的选择、缓存机制，可以将发送到前台的数据缓存起来。
6、一个文件上传控件。
7、一个支持打印的 JS 库。
8、一个创建浮动层的控件。
9、一个下拉菜单的控件。
10、一个日历控件。
11、一个绘图库，可以对 VML 或者 SVG 进行封装后实现。
12、一个所见即所得的编辑控件，例如 htmlArea。

上面这些控件中的大多数都需要结合后台的 Java 组件的配合才能够发挥最大的效用，因为它们都需要通过后台的组件根据上下文进行配置。页面中的数据如果能够与数据库中的数据建立起某种映射/跟踪关系，页面数据的 CRUD 操作可以自动转换为对数据库中数据的 CRUD 操作（要结合后台 ORM 框架或者其它某种持久层框架的能力），开发起来就可以达到一种非常流畅的效果，我相信如果实现后会有效地提高开发效率的。

何必重复发明轮子呢?

activewidgets已经帮忙做了底层的javascript lib, 并且有了一个基于这个lib实现的grid (支持xmlhttp load):
http://www.activewidgets.com/

如果真想做这些控件, 还不如加入到它这个oss项目里呢

汇报一下

1、已实现，工作得很好
2、已实现，没有问题
3、未实际用过，但是找到现成解决方案了，准备抽空试一试
4、XML本身就起到这个作用了
5、未实现
6、有很多现成的例子，现在暂时用sitemesh将页面显示为可打印版本，然后再打印
7、未实现，暂时未发现有这个必要
8、我用树实现菜单
9、已实现，在servlet中对格式进行一下转换即可
10、未实现
12、想要，但不想自己做，我想应该可以找到现成的，准备抽空试一试。

另：我想还需要搜索功能，随时按各种条件对业务数据进行搜索

to jasonhsu：
你看一下，如果没有可能开源，其实给我们提供一些指导就足够了。
据我所知，上面的这些控件很多公司都有自己实现的 JS 控件库。其实既然是很通用的需求，大家合作起来做一个开源项目是一个很好的想法。把这些东西用来作为公司的核心技术有些太简单了。

另外还需要一个对 XMLHTTP 通信进行封装，打包/解包的控件（其实基本上就是重复做 SOAP 做过的事情，但是我认为还是有意义的）。把 XML 的复杂性适当地封装起来。还要设计出一套差错控制的机制，以便出了错很容易查找到问题所在的位置。

不是不想做开源项目，但是我前面说过，一个构件级的开发框架作用有限，而且严重依赖于架构，要想让它流行起来不太可能。我觉得只有构件开发做到足够灵活、高效才能支持起架构的应用和演变，也才能适应企业级的应用需求，但构件只有在架构中才能发挥作用，无法单独作为一个应用程序来出售。一个构件在开发出来时你会觉得它很完美，但是一放到业务环境中，它很快就变得千疮百孔了，从部署下去开始就需要不断地维护它，好的系分可以解决一部分问题，但是不可能解决引起变化的根本问题，因此，一个灵活而高效的开发方法是做企业级应用所不可缺少的。大家多多交流很有意义，我更希望在这方面多听听大家的经验。

提一个建议：

要开发协调一致的框架，一定要有一个定义清楚一致的数据结构。

比如：有哪些常用的数据类型，这些类型有哪些常见的字段，如何定义这些字段（属性），怎样扩展才是符合规范的扩展。

有了这个东西，往表现层传递数据，就有了一致的基础。表现层控件之间传递数据，也就有了规范。

这个规范，肯定是要在XML的基础上进一步定义的。

其实提出Rich Client的人我想他是凭他的工程直觉，解决工程问题就是要靠分层，分层可以将复杂问题简单化，用结构复杂性换取基本构造单元的复杂性，结构复杂性是计算机擅长处理的，基本构造单元只有靠人去构造。所以这是计算机科学的最基本思想。我将我的构件架构分为五层实现（我前面描述过），这就是为了減少层之间的耦合，更符合迪米特法则的要求。我觉得我的分层不算过分，网络还分了七层呢，其效果就是我们单位做网线和打模块的人是属于物业管的，也就是说与保洁工和保安同属于一个部门，网络中心的人只管到交换机。看一看计算机分了几层、操作系统分了几层，从PN结到超大规模集成电路分了几层，我就想说应用软件的分层才刚刚开始。我说这些是想搞清楚，STRUTS和WW需要那么多的耦合，层次间那么的不清爽，修改一个文件都需要改动一大堆文件和设置，为什么仍会这么流行。ORM实现了一个明显的分层，我和大家一样爱不释手，可是到了Client为什么分岐会这么大呢。

庄兄说得很对，使用XML的框架都会遇到这样的问题，目前这些问题我分别是在JS和JAVA代码中个别处理的，主要处理过日期型、整型、浮点、字符、布尔，我也想将一些共同的方法抽象出来，不能仅靠代码的COPY＆PASTE，这样才更象个框架的样子。

我说说我现在的，算是提供参考下乐，
核心控件主要是如下：
    1、一个处理表格的控件，这里类似dlee的2、4、5应该，这个控件本身支持各种数据类型，包括日期。
    2、一个处理单条记录的表单控件，这个控件基本上是用于展示各种非表格类型数据的，它和1在数据类型上兼容，但是界面布局能力更强。
    3、一个容器控件，用于组合各个单独的控件。
    4、一个有等待提示的不刷新提交表单控件
    5、其它，比如树、工具条，这些比较雷同，

另外，数据缓存一律采用IE的XML数据岛，界面控件作为数据岛的展示和操作者，这里同dlee不同的就是，这些控件没有同server端交互的能力，它们都只是连接在数据岛上的，同server的数据交互则由另外的代码控制（主要使用上面的4完成交互）。

庄其实说的就是一个 B/S 之间传递数据的格式规范，即一个 DTD 或者 Schema 了。

我的意见是在经验还不多的时候最好不要急于制订这样一个 Schema，因为现在并不是非常清楚需要传递的数据有哪些格式。等架构有一个初步的原型出来以后，再根据实际开发经验来制定这样一个 Schema。

这个原因和 without EJB 中说的规范驱动和经验驱动两种不同的开发方式一样，庄看过我的译文，应该可以理解。过早定义这些格式反而容易束缚住自己的手脚。

至于控件之间交换数据，我觉得就更没有必要制定一个格式规范了，而且这种情况发生的其实不是很多的。