IoVC，一种新的编程思想

同感，AOM这两年的发展，偶一直在关注，在深圳开的sun技术者大会上也看过他们的演示，深深为中国人在中国浮躁的软件环境中也能做出有自己想法的框架感到骄傲。AOM网站看上去也挺火，应该是有不少实际项目在采用的，实践是硬道理，是驴子是马拉出来遛遛就知道了，接下来偶就会去验证在自己的项目中使用AOM的可行性。

另外，偶做WEB开发有五六年了，也写过一些框架，深知做好一个框架的难度。AOM不是完美的，楼上一些同学就指出了几点（比如，使用AOM后，要扩充组件的行为需要更深厚的技术功底，据我所知，现在的组件都是AOM的人自己写的，尚没有他们团队之外的人能去写组件）；但更多的，我们也要看到它的优点（比如，提升开发效率，降低web开发技术门槛等，这些是偶认可的，如果组件足够丰富，那我的团队的成员只要写好java程序就行了，不需要每个人都熟练掌握CSS/JavaScript或者dwr之类的更多的东西），但却不知道AOM触动了某些人的哪条神经？值得他们好像一叶障目一样视而未见，甚至于跳脚骂街，很是费解。

再多说两句，现在的技术论坛答疑解难的不少，大家伙都挺热心的。但点评技术的就少了，很难见到真知灼见。点评一个框架本来是善意的行为，心平气和的指出其不足之处，让其有责加冕无则改之就挺好，特别是这个框架还是国人写的开源框架，或者其中讨论的思想火花真的促进了它的发展呢？至于该框架能否能得到广大技术工作者的认可，我们大可不必去操这样的心，我们也操不了这个心，技术的发展自有其内在的规律，曾经有人喊着java已死，它死了吗？偶以为这应该是技术人员应有的心态。本帖一开始本来有点这样的意思，但慢慢的味道就不对了，实在是遗憾。

AOM是不是必须用金蝶的应用服务器?我觉得这点就特别不好

说实话,关于hax反复强调反复问的类型检查,老兄的回答让人郁闷的很,绑定的id作为字符串,如果前台代码里面id的字符串拼写与后台绑定里面id的字符串拼写不一致,静态类型检查是无法检查出来.不知道关于这点,框架是怎么保证没有错误的?

据我所知，AOM并不依赖某个特定的服务器，只要容器支持JSP2.1/Servlet2.5规范，就可以运行，例如Tomcat6。

需要注意的是，AOM有些特性是依赖应用服务器底层支持的，譬如，将一个 EJB3 对象自动转换成一个 ManagedBean，并能够在EJB对象中进行视图的绑定，这需要对应用服务器的实现进行适当的调整。针对这样一些高级特性， 无疑需要更改应用服务器的代码。 我们从不否认AOM是由金蝶中间件公司力推的技术，那么，在这样一些高级特性上， 也只有Apusic应用服务器能够支持（Apusic应用服务器是金蝶中间件公司的产品，AOM开发团队自然可以影响到 Apusic 应用服务器的发展，但 AOM开发团队目前却无法影响到其它应用服务器的技术特性）。 我从技术文档看到的...

厉害，看的一身汗...
开始  学术争鸣
后来  唇枪舌剑
           “本来是一篇挺有深度的技术争论，已经演变成一种非善意攻击了。”

轮不到俺冒头，估计有些道行的也不敢冒，怕溅一身血.....

这个也是可以做到的，在工具上将页面parse一下，取出id来还不算世界难题吧。所谓的类型检查也不是java的专利。如果约定好，id以package进行组织，工具还可以提供视图把它方便的展现出来，甚至，工具如果能提供自动完成就更好了。

你仔细看看IoVC的设计就知道这是不可能的。因为你不知道页面上的id是供IoVC去侵入的楔子还是页面本身有其他用途。除非再加上其他约定。

是你搞反了吧？是在bean的编辑器里检查，不是在页面的编辑器上检查啊，view里的id才是源嘛，只要bean中@bind了id就去看看view是否已经指定了这个id不成么？当然，这需要扩充java editor的能力，好像现在的editor都不能检查annotation中的字符串是否正确，AOM开发团队既然能做可视化编辑器，他们应该能做到这点的，只是这已经超出我知识范围，我就不坚持了。我退一步说，在运行期进行检查也可以啊，只要在运行期发现bind指定的id不存在，抛个明确的RuntimeException，有详细信息，如果我是用户，我想我是可以接受的。