IoVC，一种新的编程思想

你那意思，不是做项目，而是来玩hack的？

UI本身如脱缰之野马。我们要做的就是通过各种方式加以规约，以便驾驭。

所以你无故提供这样的功能只能是潘多拉之魔盒。

说什么怎么怎么用……那是无意义的。JSP还叫你用taglib不要用scriptlet，有人听么？况且到目前为止你举的例子没有一个有足够的正当性。

虽是跟robbin同志说的，我也来凑个热闹。

关于annotation。

我觉得annotation是个好东西是无疑的，但是我们当然也知道它所带来的耦合。为什么anno那么红，我个人觉得是原先许多解耦是无必要的，比如ORM，在多数时候把ORM规则写到单独的xml里并没有提供什么好处，因为它本来就是依赖你的Object model的，反而造成维护不便。

但是UI就大大不同。UI和app logic（更不要说domain logic）的耦合永远是麻烦的根源。

实际上，我们的问题是UI自身的logic怎么办。因为UI要越来越复杂。过去我们被迫写在jsp/taglib里，这导致一个极大的问题，就是ui logic和app logic交织到一块儿了。诚然这两者之间的界限并不是清晰的，就如同app logic和domain logic一样，有时候边界是模糊的。但是确实是存在区分。否则就不会有UI组件一说。UI组件无非是要把UI逻辑给包起来，别泄漏到app logic里。

我认为真正你要解决的问题是如何UI归UI，app归app。所以出现问题不是你对UI控制力太弱，而是你对UI控制太多。这看似矛盾，实则是深层问题的必然结果。因为UI自己搞不定，只好你想点法子越俎代庖。

关于JSF，偶只有一点题外话，取精去粗，这固然好，但是如果你们不能影响JSF的规范的发展方向，那还是白搭。总得来说，我对JSF的印象就是：它是一个续命的技术，而不是一个创新的技术。

换renderkit说得轻巧，但是是有前提的。那就是你的UI组件是足够抽象，譬如是设备无关的。那就不可能在UI组件里包含具体的style。否则我就很质疑所谓换renderkit的可行性。

因为renderkit实际是开发者所不能控制也不应控制（所谓透明）的中间层，这就说明style是不应该从你的java类穿越renderkit抵达页面的，而应该和你的java类解耦。

看了这么多，有点糊涂了。这种东西到底怎么样听来听去也不知道所以然，姑且去down个下来试试。觉得对于一种尚未了解的新技术，先不论好与坏，能给实际应用带来价值才是有意义的。

renderkit是指组件渲染的实现吧？从jsf的生命周期来看，在invoke application之后，就是组件渲染了，这个时候renderkit根据组件树来重绘页面是不是啥都可以生成？

讨论很热闹，我也谈自己的一些观点：

1. 每种技术都有其适用的场景，如果针对这种场景它能很好解决，很方便解决，那就有价值。
2. IoVC的新意不在于Controller去控制UI,而在于在web这种传统单向请求的交互逻辑下，让Controller可以去控制UI, 这在很多时候是符合思维逻辑的连贯性的，也是方便的，但是这种思想有其局限性。
3. JSF 无意去取代很多经典的MVC架构，它的目标是去提升Web的开发效率，大家都知道，在效率和优雅之间往往是存在矛盾的。我们日常生活中大部分的应用其实是更关注效率的，我想这是JSF被纳入一种官方标准，并花力气去推的主要原因吧。

4. AOM 可能在做一件事情，就是在JSF的目标下，想让日常某些Web应用开发更加快捷、更加省力一些。所以从这个角度，大家应该更多从提升Web开发效率角度，多给AOM提建议，提良策，看看还有哪些改进方向，还有哪些可以吸纳进来的。

5. 百家争鸣往往会催生很多有趣的东西，让这一起来得更猛烈些吧。

经典CS结构的MVC中，是view监听model的变化，就是说view知道并要了解model的一切，而model不需要操心任何特定的view（业务逻辑就够烦的了，还要管view的一堆烂事？？？），甚至他都不关心有几个view在关注它...

本质上是从view到model的单向依赖。

如果IoVC在此基础上又添加了一个model对view的依赖，这就把单向耦合变成了双向耦合！那个更差相信都能看得出来（搞不好还可能出现事件无限递归...）

所以你前面一说，我就知道是明显的反MVC的。

不过反就反了吧，如果没遇到事就没问题（真遇到问题够喝几壶的），现在只是让熟悉MVC的大家不舒服而已。

偶其实对MVC不怎么感冒。传统MVC在web实践中走样了。

我对你的这个论点“Controller的能力越强，MVC架构的质量就越高”不敢苟同。

事实上，我认为“View的能力越强，MVC架构的质量就越高”。

因为现在web实践的主要矛盾是UI能力不足，人们就想着法儿去只好让controller去干涉一把。

MVC的精髓除了解耦之外，更有一点是各个部件可以独立演进。但是现在的情形是V被钉死了。因为它最终就是要拼HTML（或者其他字符串），UI归根到底是任人摆弄的文本流——而不是像MVC鼻祖smalltalk里面那样V也是真对象。因为搞了半天不过是文本流，所以很难维护独立的UI logic。

名字映射当然比直接拼html是降低了耦合。但是我的问题是，名字映射干嘛是在java里的？！为什么由java来定义映射？这其实很奇怪。因为model是稳定的，view是不稳定的。由稳定的一方去映射不稳定的，结果就是不稳定被传导回去了。这种反转有什么价值？假设说，过去你在UI中直接访问java类是一个问题，现在你在java类中去直接干涉UI为什么就不是问题了呢？

其实form bean、action本身没什么不对，它至少是一种对UI的规约——它把千变万化的UI圈在一个可控的接口内，controller只要和这个部分打交道就可以了。这个思路我认为绝对没错，差的是现在的实现方式不够好。让model去随便bind住UI上的某个html元素从而干涉UI，不知道这比form bean好在哪里呢？

“model和view之间可以是多对多的映射，更可以实现粗粒度的应用组件”，“还有一种模型事件，View的动作可以触发模型事件，而Model可以监听自己感兴趣的事件”。愿详闻之。

如果View的能力越来越强，是不是说model是一个稳定的model而大部分的能力交由view来处理，这样会不会造成view端的不堪重负呢？如果万一model需要修改，那么view也不可避免的需要改动，这个时候会不会让质量下降？

抛去ajax，就传统web来说，似乎html只是view的生成品。
真正的view是模板、标签和各种其他形式的helper。

模板里面不是不能有脚本，而是不能有业务逻辑的脚本，却一定要有界面展现相关的脚本。
这个可能是一般程序员难以意识到的，即使是使用ROR也还有这个问题，甚至更盛，因为ROR的脚本更灵活。