你说的nanning简单,我认为是的,我就是要他的简单性。 在一般性的面向对象编程中,谁也别指望我去学习和应用复杂费劲的其他AOP框架或者语言。

至于低效,呵呵,我想应用实例说明了一切,一年前我就在项目中应用nanning,系统现在在运行,没有什么特别的放映。 我在系统的核心状态转移中的状态验证以及权限验证都是采用nanning,但是好像还是0.9(?)版本吧,很不错的。

另外,如果是代码增强型以及class增强型的AOP我也拒绝,nanning不一样,运行时增强。


PS: 或许你能有更好的AOP框架,不妨共享之.......
------------------------------------------------
呵呵,我说的是低能,因为动态代理实现确实有很多限制,当然也有一些优点
是否低效我想应当取决于具体的应用,反射当然肯定有开销

我对AOP没多少研究,如果我个人选择,一般情况下,AspectJ(编译时)->AspectWerkz(类装载时,也可以预编译)->Nanning(运行时)


对于AOP我所知也有限:), 我的一个朋友石一楹先生走得比较靠前。


多谢你的个人推荐。

其实我觉得validator分几种情况

一个就是页面上马上validator,比如选了a,那b,c,d马上就disabled了
还有一种,比如检查b的有效性,b必须在数据库中哪个表一定要存在,这个就是要调用后台了

tapestry不管怎么个好和不好,都是不会用了,因为是team work,不能付出这样的成本,尤其是tapestry对于整个开发模式都是新的变革

现在我的目的是使用xml配置文件来实现第一个情况,然后通过taglib或者简单的include也可以,结合iframe或者xmlhttprequest实现第二个情况
(实际上,目前第一个情况是用大量的javascript来完成,第二个倒是用iframe工作得很好)

可能有人觉得没有必要,但是需求就是这样的,我们的最终用户要求在界面上什么都显示出来,而且不可以在最后点了提交,才告诉他所有的结果,至少80%的要在他的光标移开了,他就要可以知道下一步哪些可以做,哪些已经不必要了

;-(((

应该楼上的有类似的东西,或许可以给详细点,指条明路?

Vlad,我的网站上有个连接。

看来看去,这世界上就没有一个可以根据xml生成javascript控制环节的东西

好,自己写,;-(

当然有了,Tapestry就有,不过于框架有关。


客户端验证如果你自己做框架的话,我怀疑基于Struts是否能完成?

我觉得,你如果非要在界面实现如此复杂的操作,还不如用XUL,不用相对“富”客户端会好些。用普通的Web页面看来只能把这个逻辑写入javascript的。Tapestry也是通过javascript写的,无非,它只能让页面和javascript最大程度的分离。

目前我个人在实践展现层验证的时候,复杂的验证采用的是服务端代码,简单的才去采用一些已有的组件。

当然,Tapestry的组件也是可以自己开发的。不过,象这样的东东让我去专门做个组件我也是不愿意的,除非,他确实具有通用性。


至于Vlad框架,是指Bean验证,与javascript扯不上边。:)

还有印度一家公司好像开发了一个框架,所有的展现代码都可以基于javascript编写。那样或许会好些,Webex就是这样做的。:)

;-(

我就准备以struts的validator xml定义为蓝本
定义自己的xml,写自己的生成javascript引擎去了

需求bt,这人也bt,无它~^_^

我认为,确切的说,你选择的框架或者是体系有些问题了。对于界面要求复杂的话,最好还是采用桌面技术:),现在也有许多技术在浏览器实现丰富界面的框架。比如,xul,flash,applet.......

需求是不会BT的,只要把目前的技术陈情做得足够好。呵呵。

验证的重用,很感兴趣
但我觉的有几个问题
1,就像上面说道的,有一些验证和业务相关联了,比如最大,有时候是业务决定最大多少,是一个变量。
2,通用性的验证,不同的业务的验证是不同的。
目前我所碰到的业务,所有真正意义上的通用验证,比如是否数字,最大最小,都放到客户端做了。
服务器仅做个性化的验证,这个时候,验证已经不具备通用性了,这时候耦合在一起,也是可以接受的。
这里看不出非要把业务逻辑和验证分开的理由。
aop的好处还是体现在通过灵活配置,完成公共操作,如果要为每个bean都作一个intercepter,我觉得就过于复杂了。

是的,我认为验证的粒度需要考虑,利用AOP的确需要考虑周全。

客户端验证的确诱人,毕竟让后台代码做到一定程度的纯洁。有点还是需要考虑的:你采用什么框架? 在jsp里验证,明显使得页面非常复杂,这是我们不愿意看见的。Struts的验证框架最近接触少多了,其客户端验证更加麻烦。Tapestry在这点上做得非常好,但似乎很多人不敢采用这么个框架。
当然,选择框架确实需要代价。

许多不通用的验证,我个人觉得首先考虑的是,你是不是结构出问题了,是不是把逻辑放错位置了?

其实,有时候也未必要借助于AOP,只要让业务逻辑和验证最大程度分开。采用委派往往能满足需求了。这点也是Vlad的设计初衷,它确实也做到了。

今晚我做个例子发布于erproad.org上吧。


Struts1.1的客户端验证是通过配置完成的,这就极大的简化客户端验证的工作,并且也提供了扩展,对于是否是数字,正则表达等多数应用都能满足。再配合xdoclet的使用,很方便。
最主要的缺陷是1,有bug,不完整
2,使用自动验证意味着actionForm通用性下降,比如在一个form里面的数据需要在两个页面里提交,则需要两个不同验证脚本。当然也可以迁就actionform这种特性,做两个actionForm.
3,如果重载validate方法,实际上完成的是服务器端验证,但此过程在执行业务操作之前,某些需要业务数据的验证则无法放在这里。当然也可以认为此类验证属于逻辑部分,就应改在业务过程中。

另,struts验证部分单独分理处去形成common-Validator。
最近正在看spring的源码,里面也有一个类似的包,似乎采用的是ioc的方式,也在一定程度上分离验证和逻辑。

许多不通用的验证,我个人觉得首先考虑的是,你是不是结构出问题了,是不是把逻辑放错位置了?

哪些属于验证,哪些属于业务这个没有什么标准,要想验证通用,验证尽必须和业务无关。个人理解,struts解决的都是和业务无关的验证。spring吗,还没有看完,但猜测也一样。

呵呵,即使是做桌面,也是面临一样的问题的
想想,就是用了swing,也是一地listener的东西,区别不大
还是要想办法统一起来
人在江湖,不是说自己想用什么就用什么
我也没有十足的道理说用什么好,只是知道,那么ugly的javascript也用过了,而且跑得上好,我就不去提一个新的了
尤其是我来带team的情况下
想想,我都搞不明白的,还是带着人来做,不要了吧~,嘿嘿