一个不错的web UI开发的解决方案，有工具包，有Eclips插件，在eclips里开发web应用，有点想swing!!
http://w4toolkit.com/
> 服务器上运行，而不需要改代码。
>
> 其实它就是在WEB层加入了对 Swing 控件的支持，利用 HTML
> 做控件的绘制。另外，开发者还写了JavaScript来模仿
> Swing 中的事件。像是在 WEB Container 里模拟了一个
> Swing 的 Container.
>
> 不过，这样的东东是否能承担大的访问量，我就不太清楚了。
>
两种办法，但是自己都没有亲身实验过
1。使用Web Start
2。Applet可以使用Swing，但是好象需要认证
看看这个吧, 下一代windows用户界面 smart clients ClickOnce
>
> 至少，struts不能解决错误提示在focus离开的时候就显示给?> 户
> 比如，只能输入数字是最简单的，这还是javascript
>
> 的确，楼主说的n-tier的问题的确是存在，我们也一直在苦?> 飧鑫侍猓钔反蟮氖潜呓缍嗔耍tier多了，处理起来更加麻?> 了，查个错也要满地找牙
struts可以自定义validator的，可以解决这个问题。
> >
> >
> 至少，struts不能解决错误提示在focus离开的时候就显示给?
> 户
> > 比如，只能输入数字是最简单的，这还是javascript
> >
> >
> 的确，楼主说的n-tier的问题的确是存在，我们也一直在苦?>
> 飧鑫侍猓钔反蟮氖潜呓缍嗔耍tier多了，处理起来更加麻?
> 了，查个错也要满地找牙
>
> struts可以自定义validator的，可以解决这个问题。
>
原文：struts不能解决错误提示在focus离开的时候就显示给用户
背景
传统的应用程序体系在客户端运行业务逻辑并提供丰富的GUI图形界面。同时，GUI界面上很多供应商提供了丰富的WYSIWYG(所见即所得)的开发工具，比如Delphi,VC,JBuilder等等。随着n tie体系结构的提出，业务逻辑集中的概念，组件的概念逐渐深入人心。于是越来越多的技术人员投奔于n tie。业务逻辑集中的确给程序的发布和维护带来了很大的方便。 但问题也随之而来：
1、客户抱怨界面太过于简单且不够好用。很多功能诸如参照、智能化输入、多窗口等等因为基于request的b/s结构。烦恼的不断刷新，烦恼的刷新实现。
2、报表系统不是太慢就是太过于简单，同样存在不友好的问题。报表工具我该用什么？复杂的实现？
3、设计上来看，由程序员去设计HTML页面确实不符合社会分工的原则。:)，老天，WYSIWYG，dreamweaver我只会用一点，photoshop我根本不会用。
4、展现层上存在业务逻辑的结果是代码不复用。 混乱混乱，我的中间层怎么成了SQL执行器？
5、javascript以及css，说道，真挺令人厌烦的。 javascript?怎么浏览器换成Mozilla就不能用了？烦恼。
6、如何让我们的展现层和做类或者组件那么简单呢？面向对象？我这到处代码嵌入的jsp页面，是不是面向对象programm？
[常见的]
1、ActiveX？ 不好玩，机制复杂，依赖操作系统，入门不容易。支持浏览器似乎不多吧。容易写逻辑代码入客户端。容易感染病毒。
2、javascript? 烦烦烦，他不能做一切事情。
3、直接客户端编程，编制？数据传输、安全等不管再说，需要维护，需要发布？需要两个存取层了？回到了远古时代了:(
4、直接做自己的客户端浏览器?实现自己的展现层逻辑，不是一般公司能做到的。看来也不经济。
选型思路
1、客户端不需要发布，最好什么都不需要安装， 我要rich thin-client architecture.当然，除了浏览器.
2、我要Form,要Grid，要操作系统上所有的控件。丰富，丰富，还是丰富。
3、什么操作系统都可以用，我不想被什么操作系统束缚。
4、我不要不断的刷新，明明我什么仅仅变化一个条目，他干嘛把我所有的东西都刷新？好慢
5、报表，我怀念delphi时代的报表
6、程序编制简单，不要没完没了的机制，希望用的所有的东西都是我所熟悉的，我不想再学习一们语言了。我能很快入手嘛？
7、不要付费吧。 我已经买了太多的软件了
8、想到了再告诉你......
已有的一些工具和体系评价，你来....
1、XUL
1)LUXOR
2)
2、Flash MX
3、curl
4、XWT
5、JellySWT
6、JellySwing
7，Swix
8，KoalaML
9、Thinlet
10、Axualize
11、Isomorphic SmartClient
13、Xforms(?)
Tapestry是可以的。基本验证组件就支持
比如说，单据中有费用1和费用2，同时还有一个合计＝费用1+费用2，如果所有的这些都写到服务器端的话，那得考虑考虑网络流量的问题了吧！
其实我觉得N层体系并不代表说需要在物理上的应用程序的分离！
我觉得可以继续采用C/S结构，但我们的Client必须是可以自己更新的，同时需要让C和S的数据传递通过防火墙。那么也就是说，我们可以用我们的Delphi等这些工具来写客户端，而通过java来写服务器端，客户端通过WebService来调用服务器端的服务，而对于安全方面可以用SSL等这些协议及可满足安全的需求。
再让我们看看所谓B/S的免安装吧。
1、Applet技术方式。你能保证你的这些客户端都安装你你所希望的JRE？没有的话你还是得安装。
2、ocx技术方式。写起来就痛苦。
3、纯Web。基本上来说好像都要浏览器进行些限制。你看看现在的网站基本上都写着IE5.0以上！如果是用98的系统你得从装IE吧！如果是Linux，那很多东西小恐龙都吃了都消化不了，你还得调！
所以，我不认为用B/S方式就是真正的免安装。而其最大的好处就是可以自动更新你的程序，而对于C/S的结构你的Client只要写的好，也一样可以动态更新！
>
> Struts+EJB再加上J道数据操作通用开发框架，80%可以满足楼
> 鞯男枨螅獯握娴牟黄恪?>
> [url=http://www.jdon.com/product/struts%2Bframework.ht
> ]http://www.jdon.com/product/struts%2Bframework.htm[/u
> l]
banq太自信了，楼主说的是GUI的问题，不是框架。
举例说明：
1)某个表单对应数据库中“USERNAME”字段，用户会要求输入拼音，系统自动由拼音转化为汉字。（最好是自动完成的SELECT）
2)用回车键切换表单focus。
3)禁止输入汉字。
4)用图形界面实现日期表单的输入，就象CDatePicker。
5)一个页面输入了50个数据，但是只需要提交3个数据。
6)文件上传的时候一次选择多个(多次选择太麻烦)。
7)真正的多线程进度条。
8)页面上的消息处理。
9)打印和打印预览。
10)报表、曲线、柱状图...
...
banq,struts + EJB + J道框架能解决上述10个问题的8个吗？不要告诉我用Applet，客户端没有JVM，只有win98+IE.
所谓框架、EJB之类的DD都是解决server端的问题。软件的易用性还是要依靠client端。
1.rich client可能满足， 你看看有关xul的资料，现在这方面的研究也很热。
2.b/s结构上的报表系统确实是个难解决的问题，看看openreport如何。
3.客户端上实现所见及所得的很容易实现， 实际就是一堆js,产品很多。
4.设计问题。
5.如果用js的话， 最好找些使用用户比较多的代码， 他们一般都会自动适应ie/mozilla, 要是自己写，那就看看mozilla的js语法。别怪mozilla，这都是微软使的阴招。
6.用mvc
jsp,struts + EJB
关于楼主讨论的这个话题，我是深有感触的，但也不像很多人说的那么严重。
先讲一个细节：
业务人员在用IE打开我做的一个报表界面后，第一个动作是用鼠标拖了一个表格中间的竖条，然后很惊奇的说了一句：咦，这个怎么不能拖宽拖窄的？（他是指像Excel的单元格那样），你这不是最新的技术吗，这么这都做不到？
我无语.....
用B/S在界面的控制上的确有难处，我想这个罪过首先应该算到微软头上，它做IE时为开发人员考虑了多少？要是不是netscape出了javascript,现在有没B/S的提法都是问题。（不要跟我说JScript哦，那是MS跟人家学的)
但大家也别小瞧javascript,其实还是够猛的，只是深入学习要有点耐心，它的很多东西感觉与其它语言格格不入。不过学习来还算容易(所有网站的JAVASCRIPT源代码是完全公开的。没有比这玩更open source了的吧）.深入学习后会发现javascript对界面的控制其实足够强大。
我只举一个例子，利用javascript可以做在不刷页面的前提下，动态的与数据库交换数据，如果大家不信，可以去好好研究一下www.chinajavaworld.com的论坛。
至于普通的验证就更不用说了。
在目前没有更好解决办法的情况下，而又对B/S结构情有独钟的（包括我自己），建议好好研究一下javascript,虽然开始用起来麻烦一点，但大多数需求还是可以满足的。
至于用applet,activeX,包括PB等很多开发工具也有发布WEB应用的功能，我觉得不到万不得已，我是不会用的，繁杂不说，界面控制太不灵活.
最后说说关于Struts的，我个人认为它与界面控制没关系，它是提供了一个中间层，很好的实现和封装商业逻辑，而且用起来绝对是比单纯用JSP简单了而不是繁杂了（当然要看你能否接受新东西）,所以顶它没商量！
但是，它也不是像很多人吹的那么牛（我都怀疑那些人实际用过没），根本做不到把JAVA语句与JSP页面完全分离，返回的那些ResultSet 或是 Collection,怎么也得写语句控制吧.
目前我看到过或者听说过一些rich client的实现，都不尽理想。包括我自己的Ivory框架。
目前rich client框架（这里说框架是有原因的，因为rich client并不单纯解决GUI问题，还同时带来许多分布式系统固有的问题）还真的不少，能够真正可伸缩性的却有不多。
BS-Factory是我见过开源项目中比较完善的解决问题的框架，非常优秀，可是他又要让我非得用ejb不可。
可能缺少一种标准吧......