建议你看看org.apache.struts2.interceptor.validation.JSONValidationInterceptor，那里有你的做法，至于不跳转嘛用Action.NONE或者return null也是可以的，当然jsonplugin也提供了很好的途径，而且我认为不应该直接用json-default（还有defaultStack)的配置，或者说本身就该定制自己的ajax的interceptor chain，和默认的Interceptor chain。

好恶心的英语，囧rz....

嗯，要学习一下Lemuel，即便是对于一个example也要认真对待，应该限定一个滑块的底线到透明度的20%就应该不存在程序完全看不见的情况了

对于今天的硬件来说，这个小程序运行速度完全不成问题，不管是不是冷热启动

我也很幸苦哟，每天都是牺牲午休时间来写写，改改，再说，现在这个截屏都还改不够呢...

你的截屏程序让我眼前一亮，我只是觉得你不继续更新，可惜了，有多少人因为嫌弃记事本、聊天工具、通讯本、贪吃蛇、俄罗斯方块之类的只是熟悉GUI和算法、模式之类的“练手”东西而在学会之后就不再继续了，结果埋头继续的，认真对待的、持之以恒的人最后都因为这些“练手”的东西而著名或者发迹了，而那些只是为“练手”的到现在还在继续找东西“练手”。

一般人天天都做了一个东西，即便是再喜欢久而久之也会产生审美疲劳，唉。
例如Hibernate吧，第一次接触它就喜欢上了ORM，那个时候还在上大学，然后天天就捣鼓这个，课也不上，兴致高昂得连什么hbm文件，事务之类都是亲历亲为，但是自从工作就是跟它打交道的不久之后，就开始用生成工具来生成hbm，然后不久之后开始用AppFuse了，就连hibernate那几个CRUD操作长什么样都不知道了。

NO、NO、NO，我的工作是JavaEE，天天都伺候着Spring、Hibernate、SpringMVC、DWR……

我最近的工作就是将很多用Excel做得各种记录之类的导入到新的数据库里面，最大的一个Excel文件有3000多条，虽然不算大容量，不过也不是很慢啊。

我也改造过SWT的,是有点古板，土的掉渣这个就有点...

BeanSoft兄，何必舍近求远去找一个L2fprod呢，JDK里面就有现成的Metal和windows等等LookAndFeel的范例。

不过我想问一下，LookAndFeel的这种设计是一种MVC吗？也许在下驽钝，理解的是一种策略模式，将组件的paint方式交给了各个LookAndFeel的实现来完成，然后由用户通过UIManager来决定装载的不同，从而调用不同的绘制策略。

“更好的”方法比“更适合”的方法获得的效率差太多了，如果采用了BeanSoft兄的方案，那不知道要有多少步才能看到在下这个界面了，继承LookAndFeel，写ButtionUI，...，启动程序的时候装载这个LookAndFeel类...,在下只是改造一下JButton，何必非要为了JButton弄一个LookAndFeel出来呢。其实为什么大家都喜欢Spring多过EJB呢，为了迎合一个框架我们做得无用功太多了，而Spring给了我们自由的选择，但为了Spring我们也做了很多无用的东西，所以才有了AppFuse（大师说代码生成是罪恶，所以我们也该反对AppFuse？），才有了ruby on rails。聪明的人虽然也会按照成规办事，但是他会选择最适合他的成规，如果没有他宁愿尝试创新，否则，也不会有这么多新的框架如春笋般冒出来了。

也许可能会觉得我太注重实际的结果，用户的感受而忽略了作为一名不断上进的开发人员需要的学者学术般的研究和讨论，这可能才是BeanSoft兄“更好的”含义吧。我会多多改进的。

P.S 怎么感觉像是DDL和蝎在讨论什么才是艺术？嗯

好好好
我就迁就你们这些懒人，下次不带行号了。

Thanks，是个很好的建议。呵呵，这样是不是有点像SWT的Style了。

不客气，多多交流，我也在这里开张了，以后在下就不用someone这种藏头露尾的方式来交流了。