IoVC，一种新的编程思想

Annotation在Guice接触过一些
现在就在用operamasks做东西，确实很好用，但不能和其他JSF项目共存于一个服务下让人纳闷！

既然hax兄喜欢逐句评论的形式，那我也入乡随俗吧。毕竟理解万岁。另外与技术无关的比喻，既然hax兄不满意，也就少说为妙了。

1.“偶是没用过AOM，因为我对JSF根本就不感冒。而且我没有必要也没有义务先要用过AOM再去批评它……”这个当然是没有义务的，至于必要嘛，很难说。那要看hax兄的职业是一个科学家（技术人员）还是一个批评家。如果是批评家，自然可以想批评什么就批评什么。如果是技术人员，打着科学的旗帜来批判，那最好还是先做点调查哦。。。连JSF都不熟悉，只是凭着对自己现有知识的一腔热血，对批评的对象的一大堆的“我猜”，但又摆着统揽全局的姿态来批评，那就的确就点那个“井底之蛙”（按hax兄的建议，这次就不藏头露尾，枉作小人了）的气概了喔。。。

2.关于id为什么会变hax兄懒得回答，我是意料之内，所以我也没有去真的走去问前端人员。不然就算辛辛苦苦问了，人家说不会变，hax兄还是说我懒得理你和你的那个前端，岂不是白搭。。。

对于“框架的作用就是找到一个平衡点，并确保或至少引导开发者始终保持在这个平衡点附近。”这一句我是不敢苟同的，综合以上几个贴子，我觉得hax兄对“程序员”这个词的感觉是一堆前后逻辑毫不连贯，总是在合适的时候做出你想象中行为，所以需要你去引导的群体，而不是一个一个有统一思想的个体。例如说，你笔下的程序员可以今天思路清晰地使用facade、adapter、proxy、bridge等设计模式去保证model接口稳定，可以如有神助地预见到需求的变化而在合适的地方引入抽象。但明天又会突然之间分不清UI行为层与业务model层，在IoVC的“误导”下胡乱涂鸦。如果真得有这样一群程序员，那么就真的可能市面上会出现一种仅仅为了限制而限制的框架。但我所认识的程序员(结合他们手上的项目)，没有一个是这样的，他们要么就是明确的架构主义者，善用抽象，熟悉模式，并不需要框架来“引导”，反而如果框架的所谓“引导”（事实上我认为是为了提供方便所制定的规则）与他们的原有知识不吻合，他们可能会反感（hax兄自己是个很好的例子喔，你的信仰是“程序员需要限制”，于是对任何“没有提供必要限制”的东西就会极端反感，虽然我引导了很久，还不是照样不以为然。。。），这时除非框架本身能提供足够的好处，否则他们不但不会接受你的“好意引导”，反而会对你嗤之以鼻。要么就是明确的反架构主义者，他们可能只做轻量级的项目，对分层，模式什么的不以为然，只求尽快把项目做完交货，功能完备，万事大吉（这个群体可能不入hax兄法眼，但是客观存在的，特别在应用软件行业中），对于这个群体你在框架里故意给他加限制那叫自取其辱，要么想尽办法把限制绕过去，要么就直接弃用了，他们不会喜欢一个没有带来任何方便，仅仅是为了所谓的“风格”而加入的限制。还有一些可能还没有如此明确的立场，可能选择任何框架，接受其编程模型，那就至少不会前后矛盾，故意跟他选用的框架过不去，那么框架的编程模型，本身就是一个软限制（如果他在项目组里，那么项目本身现有的风格就是他的限制，会有相关行政措施来保证），而不需要在框架里画蛇添足地情愿牺牲易用性或者性能或者任何其他东西（例如直接牺牲了前面的两类用户群）去专门引入硬性限制。目前最被人们所喜爱的限制，是那些可以帮他们找出“bug”的限制，例如强类型检查，例如java里不允许在if条件中使用赋值表达式，为什么？因为这些限制，给他们带来了方便。但象hax兄例子里那种，放弃了编译检查，又滋长同步冲突，又没有提供任何方便，越帮越忙，仅仅是为了提供规约，号召所有程序员都按着hax兄的思路走的框架，没做出来的时候，看着是觉得挺好。但做出来了有多少人会去用，那就要打个问号了。

“既然认为美工不应该用el，那为什么美工应该用taglib或任何除了html之外的markup？” —— markup是相对稳定的标准东西，超然于业务需求之外。el是各种各样的项目里各种各样的程序员（例如，可能是以上三种的任何一种）写的方法签名，受业务需求影响。不知道这个理由是否充分？

“这里有谁写好java类之后从来不改类名和方法名的？难道就java开发人员掌有“命名”事物的权力，而美工和前端开发者就没有？” 变了类名和方法名，那就要改view中的el。变了id，就要改程序中的绑定，至少字面上比较起来就没有差别呀。但前面说过，类名和方法名改动的驱动力是业务逻辑变动，是程序员自身无法控制的。（除非你用了一大堆虽然不是吃干饭但是要吃很多饭的抽象层去保护它，而且还不一定就能保证绝对不变），我上个贴子问的就是，请问前端人员改id的驱动力是什么？只是为了展示他们的权力？

“但是遇到稍微复杂一点的ui logic怎么办？好了，AOM出hack了，第一招叫做attribute侵入，第二招更狠，直接生成一些javascript嵌入进去。我其实还没有提别的问题，比如我一个view上要用一个model的两个不同的instance怎么办？我猜他就是换一个attribute来侵入，或者还有其他狠招。” —— 不如你说说到底是什么逻辑，我们大家给你想想办法啊。你又不熟JSF，又不熟AOM编程模型，只能猜到这两招是很正常的呀。。。“我一个view上要用一个model的两个不同的instance怎么办”这个东西你平时用el怎么办，我用IoVC就怎么办呀。一般就是在原来的el前多加一层可以分别出两个实例的引用，用IoVC就是把@Bind的getter（两个组件绑不同getter）里引用不同实例。或者，最简单的是，可以用IoVC在ManagedBean里往组件里填el。

BTW那段完全没有看懂，先不妄自推测了。我找你要统计数据是因为你说“展示逻辑变动必然比业务逻辑快”，是要直证（也就是说，要么说出明确的推理，要么举出压倒性的统计数据），我说的是这句话的反面，也就是“不必然”，只需要反证，举了个google足矣，还搭了个MSN，顺带提及了其他电子商务网站。你别管它软不软，反正就说明了“不必然”。“你的约定要是基于过分简化不切实际的假设，那约定得再简单再漂亮也就一个词：意淫。”这句话我绝对同意，特别是“要是”两个字，例如那些不是开玩笑的全部默认绑定云云。。。

“在AOM眼里，view就是一个架子，根本没有logic的”——如果要套上你的有血有肉view的分层，在JSF编程模型里，这个view是由makeup写成的页面与ManagedBean（AOM中改叫LiteBean，因为提供了一些非标准的特性）组成的。makeup只管展示（标准JSF中还管绑定），也就是根本没有logic那部分。ManagedBean管数据和行为（IoVC中还管绑定）。

“虽然他像模像样的说，我们没叫你把style写到bean里——废话，JSP也没叫你把jdbc写到JSP里。”——问题是，现实中的确有人在JSP里写jdbc呀，难道目前有任何一个框架一发现有人在JSP里写jdbc就抛异常？按照你的“框架就是要规约”的理论，个人建议你，可以上书JCP建议JavaEE7不允许在JSP里写jdbc，没准就通过了。这可比跟AOM说事有意义多了！

“我们假设IoVC是把与纯粹的ui控件（空架子）无关的部分解耦出来了，放到了model里。问题来了，你的model到底是什么model？”——如果你严格分层的话，再把业务逻辑和界面行为逻辑分一层，那么ManagedBean部分就是界面逻辑层。当然JSF和AOM都不会用技术手段硬性规定你不准在ManagedBean里写业务逻辑（但不推荐），所以如果想牺牲架构清晰度去换方便（例如自己随便写个小程序玩玩时），也可以把业务逻辑写在ManagedBean里。

关于你随手写的例子，我想问的是，如果用了你这个框架，用户付出了什么，得到了什么？仅仅是“喔，原来el是应该属于view的”？还有我想问下细节，假如你真的推出这个框架，做不做代码提示？如果我一个view写了超过一屏，我每次加el的时候，要鼠标滚轮滚滚滚滚到开头，加条定义，再滚滚滚滚到原来的地方，加条引用吗？还是我跟项目经理说，要写这个页面必须配备两个人分开写开头和中间，你要我一个人写请给双倍的时间或者双倍的工钱？如果你是分开多个独立文件，那我在阅读代码时，看到一个bind="name_of_manager_in_sales_department"，又或者bind="b_id3342" (当然，我估计你的框架是会通过某种人工智能禁止这种写法的)，是需要用目录搜索工具搜索才能看到实际的el吗？我相信任何一个程序员，做完这种事之后，发现这个引用只被使用了一次，第一个反应是：“你是在耍我吗？”。框架这种东西，想起来是很舒畅，要实现一个出来还要让人能用可不简单呀。

“谢谢你告诉我@Bind可以绑方法，我终于可以写jdbc啦！”——请hax兄写信JCP的JSP项目组时，顺便给JSF的项目组抄送一份。如果标准JSF禁止了，AOM再把这个限制打开，我相信至少又比其他标准JSF产品多了点竞争力。

“甚至，如果是我写ui，而且ui需要的bean都简单得跟IoVC的例子那样，我根本不会把bind单独写到model部分里，而会直接在markup上用el。”——如果个个前端人员都象hax兄一样强劲，我猜这种技术力量乘上这个群体的人数（或者再加上其中的MM人数对其他群体的影响力），足够发明一种简单易用的框架直接把业务逻辑做在前端还能保证各个客户端与数据库信息同步，并解决业务逻辑同步更新问题了。

“两个ui control绑定相同的bean，难道你要他们有相同的id？”——这点的确有道理，我回头跟AOM团队的人交流一下他们有什么解决方案再说。但最简单的，你还是可以直接在页面写el来绑。已经说过，AOM的好处是，如果你的需求超出了它目前实现的能力，它没有给你添加任何额外的麻烦。最多在特殊的那一点上打回原形，在任何其他在它能力范围内的东西还是可以继续享受它的功能。

“强类型检查很了不起吗？虚幻假象！”——也不是很了不起，这东西既不能令程序优雅多少，又没有引导人们奔向美好的架构。对于批判家们是一文不值的。但对于干dirty work的应用软件程序员，还算是聊胜于无的。

“是可以通过工具检查出bind的有效性的。如果bind属性和bind元素的id匹配不上，就说明有错误。”——你意思是，你的model里的条目，如果没有现实的bind跟它匹配，你就会抛异常？这功能有点古怪喔，如果你的model要重用，还要把新view里没有用到的bind id删掉？还是要把新view和原view共有的bind条目抽取出来做一个新文件，各自特有的分离为两个新文件？那如果用户分离了之后，突然又想不要新的那个view呢？我很是怀疑到时候你会做这样的工具，还是偷懒直接把这条判断去掉了。。。

“我确实是这样推定的。因为AOM那篇文章就是这么说的”——说了可以的，就一定可以。没说可以的，未必一定不可以喔。这好象是小学生的逻辑题吧。。。特别是在产品特性介绍文档里。就算是参考文档，也没人会把所有“不可以”的情况的列出来的。遇到一个文档里没提的特性，动手试一下，这是任何一个程序员的基本常识吧。。。就算你不试，最多就不用那个特性了，也不可以基于假设继续往下写程序呀，这可是大错特错的行为呀。但hax兄是基于一些假设用绝对的语气写了一整段文字喔。。。

“我其实还想问，既然不是因为这个原因，那么@BeforeRender有什么用？”，目前按我的理解，就是在这个方法里可以在JSF的Render Response阶段——啊，忘了你不知道——就是一次请求中，所有业务处理已经完毕，IoVC绑定已经完成之后，根据组件模型构建响应结果之前，给一个机会用户插手做点事情。一般来说，希望在IoVC绑定之后对组件树作动态修改的逻辑可以放在这里。

“我来看例子，不是看他的使用方法的。而是要看他的理念。”——你在产品特性介绍文档举的简单例子里，既不看说明文字，又不理解JSF本身的前提下，想看理念，这也就怪不得你会不满意呀。

“请问google这样的ui要IoVC干嘛？它什么web框架都不要，一个最简单的html就完了。捡软柿子捏也没有这样的，我还能说什么呢？” —— 本来上面已经提过，我又怕你又忽略了，重复一下，顺序看下来的其他读者请跳过本段。“BTW那段完全没有看懂，先不妄自推测了。我找你要统计数据是因为你说“展示逻辑变动必然比业务逻辑快”，是要直证（也就是说，要么说出明确的推理，要么举出压倒性的统计数据），我说的是这句话的反面，也就是“不必然”，只需要反证，举了个google足矣，还搭了个MSN，顺带提及了其他电子商务网站。你别管它软不软，反正就说明了“不必然”。”这个其实跟IoVC没什么直接联系，并不是说google就要用IoVC（哪天真的是的话AOM的朋友可记得要请我喝酒了），只是说现实上就存在着展示没什么需求要变的项目。

“他已经有@LiteBean了。”——我也想过让LiteBean具有这样的特性可能挺好，但后来又想事实上有很多LiteBean是带有自己内部用的私有field的，在JSF的编程模型中它还可能要管页面行为。那么不符合这个约定的LiteBean就有可能挺多，正如你所说：“你的约定要是基于过分简化不切实际的假设，那约定得再简单再漂亮也就一个词：意淫。”，所以提建议时保守了点。具体怎样搞请AOM的团队斟酌吧。

“需要么？按照IoVC，一切都绑定又怎么样？你view上没有id不就好了。”—— id除了做IoVC还有可能是css或者javascript的标识呀，而且按照AOM的角色职责，应该是前端人员告诉程序员用了什么id，而不是程序员去告诉前端不准用什么id。这种基本东西AOM还是考虑到的。。。

“我为什么说他心虚，前面已经说得很清楚了，不再赘述”——我为什么说他不心虚，前面已经说得很清楚了，不再赘述。（感觉又回到了充满童真的小学时代。。。）

类似ext这样的ajax框架其实正是 基于browser/webserver平台的 C/S，传统的C／S结构似乎在回归。只不过原来基于操作系统的client变成了基于浏览器的，通信协议也由私有二进制变成了基于http的明文协议。

技术的发展似乎在螺旋上升。

现在的花花概念真多，JSF就是这样用的，<w:textField value="#{myBean.value}"/>，这样只是取数据方便点，实质上myBean仍然在request或page或session里，只不过框架为你做了这些事情，本质上没区别。

没空也没兴趣在这里给连反问句和归谬法都看不懂的人上逻辑和语文课，偶也不想骂人，俺毕竟不是ajoo（不过说不定也会忍不住哦）。我就挑几点跟实际技术有关的：

“最多在特殊的那一点上打回原形，在任何其他在它能力范围内的东西还是可以继续享受它的功能。”

你认为“两个ui control绑定相同的bean”是特殊情形？做托也没有这样做的。一个框架如果过分简化到连这样简单的需求都做不好，那是该被“打回原形”了。
我之前还举了其他几个例子，所以不是“特殊的那一点”，而是“特殊的那几点”。请AOM的人和AOM的托回答，IoVC怎么解决“特殊的那几点”。

“强类型检查也不是很了不起，这东西既不能令程序优雅多少，又没有引导人们奔向美好的架构。对于批判家们是一文不值的。但对于干dirty work的应用软件程序员，还算是聊胜于无的。”

你甭在这里混淆视听。我从来没有大而化之的批评强类型检查，相反我很喜欢工具来帮助我检查。但是我为什么说它虚幻，请你再好好看看我前面写的理由。

“你的model里的条目，如果没有现实的bind跟它匹配，你就会抛异常？这功能有点古怪喔，如果你的model要重用，还要把新view里没有用到的bind id删掉？”

uicontrol里面的bind属性所引用的，必须要有model里的bind元素对应，否则就是错误，而且这里可以进行类型匹配检查（真正有用的检查，而不是IoVC那种虚幻无用的检查）。没有用到的bind元素是不必删除的。bind的真正含义就是model提供给view的一个接口，uicontrols可以用也可以不用，主导权在uicontrols手里。这个依赖方向是很好理解的。

“目前按我的理解，就是在这个方法里可以在JSF的Render Response阶段——啊，忘了你不知道——就是一次请求中，所有业务处理已经完毕，IoVC绑定已经完成之后，根据组件模型构建响应结果之前，给一个机会用户插手做点事情。”

为了照顾某些人的理解力，我再用大白话说一遍：如果model只是view的model——不含有app logic的话，而且可以写getter——因而不需要去靠初始化去填充，那么它为什么需要这个机会去给人插手？

“应该是前端人员告诉程序员用了什么id，而不是程序员去告诉前端不准用什么id。”

你确认么？你真的确认么？你真的真的确认么？


如果你真的认为自己确认这一点，那么请代表写model的java程序员做以下两项思考题：

1. 请想一下，这样的开发模式是谁驱动谁。如果发生表现层的需求变化，会是怎么样的流程。
2. 考虑一下，前端人员能否准确告诉你你所关心的那些id？
3. 考虑一下，当页面变更时，前端人员能否记得哪些id是与你有关的，因而不动你的奶酪，或者动了之后能记得通知你。
4. 页面已经做好，你逐渐添加功能，一切顺利。但是你今天要新加一个功能时，恰巧今天前端人员不在，而你又忘记了他告诉你的那个id名。作为程序员，当你面对页面里成百上千的id时，怎么办。有什么办法消除这类问题？

...大家好好的讨论技术，干嘛要想骂人呢，有话好好说嘛。至少我觉得技术论坛讨论技术问题，出发点是，第一，帮助自己理清思路（在与hax兄讨论的过程中老实说我是获益不浅，有很多以前没有梳理成线的东西在hax兄的启发下也有了重新的思考）。第二，与大家分享一下看法，满意的顶下，如果有不同的见解，提出来，思考在碰撞中才会有火花。即使意见不合，大家也是寻求一个双赢的局面而已。所谓无欲则刚，如果不是出于某些原因非要把对方按倒不可（谁知又没按倒），怎么会想骂人呢。。。

逻辑课和语文课就还是不用hax兄来上了，前面还有很多逻辑问题还没搞清楚呢，只要hax兄能把之前遗留的问题说清楚了，已经感激不尽了。至于我的身份，还是请hax兄不要猜测了，正如hax兄从开始在这个贴子里那是尽心尽力有贴必回，用词之激烈，一时无两。前两天看hax兄blog里还有篇技术论文跟AOM的一篇市场宣传文章抬杠。嘿嘿，自己不都觉得自己是托，反而别人只要偏向APUSIC就一定是托，难道一定要跟hax兄意见一致才算是真心实意吗，“非我族类其心可诛”？而且我也一直没在hax兄的身份上做文章嘛，讨论技术，说理而已，难道还要看看家庭成份吗？只要说得有理，身份很重要吗？目前几贴我都是单刀赴会，又没与什么人唱双簧，是路过也好，是托也好，甚至是他们公司的人也好，有任何问题吗？至少我第一贴，只是借了hax兄的一段话，引申出自己的观点而已，没有任何搞针对的意思噢。火药味是在hax兄的逐句分析帖里弥漫出来的。。。

“你认为“两个ui control绑定相同的bean”是特殊情形？”我没说这是特殊情形，我说“你说得有道理，我要问问他们怎么解决”，今天我大致问过了，的确目前对于这种情况暂时没有很好的解决办法，对于这种情况，目前是要采用直接写EL的方式。如果你觉得“AOM的好处是，如果你的需求超出了它目前实现的能力，它没有给你添加任何额外的麻烦。最多在特殊的那一点上打回原形”这里的“特殊那一点”很碍眼，那就罗唆一点改为“最多在超出了它目前实现能力那一点”吧。意思能表达到就好。

“uicontrol里面的bind属性所引用的，必须要有model里的bind元素对应。没有用到的bind元素是不必删除的。” 嗯，这个方向的确可以说得通。再结合上面的问题，现在我也觉得的确在绑定属性上，可以考虑不用id，而用一个专有属性。这样就在IoVC中可以引入同样的绑定检查，并且同时解决两个uicontrol绑定的问题。

“我之前还举了其他几个例子，请AOM的人和AOM的托回答，IoVC怎么解决“特殊的那几点”。”，如果我没记错的话，你举例子的问题我应该都尝试做了回答，你说得有理的，我也明确正面说了你说得有理，自我感觉还算是虚心受教的。你确认不是你又跳过了？也许有些地方我没看出是举例子提问题，请hax兄明示。

“你甭在这里混淆视听。我从来没有大而化之的批评强类型检查，相反我很喜欢工具来帮助我检查。”你那句连道理都没说的“很了不起吗”算不上批评，最多算是摆摆姿态。如果你很喜欢类型检查，那么我再把本来的问题问一次：“为什么IoVC直接在java bean中需要绑定的地方打标注，能在模型端享受强类型检查的做法是退化，你的model文件要写个无编译期检查的接口签名还要写个id的做法是进化”？就因为你觉得那东西为用户增加了你觉得非常重要的所谓规约吗？当然，如果hax兄精力旺盛有空去为eclipse，netbeans，intellidea等等各种java ide写个这种框架的检查插件，那也是可以的，虽然自己麻烦点，至少用户不会讨厌。但就算这“规约”本身不算一个麻烦，额外增加的麻烦还不只没了编译期检查这么简单。

“如果model只是view的model——不含有app logic的话，而且可以写getter——因而不需要去靠初始化去填充，那么它为什么需要这个机会去给人插手？”你在没有说服别人“框架即制约”之前，不能老把这个自家标准到处套呀，既然标准JSF不限制别人写phase listener，你为什么就不准AOM用标签指定phase callback？我在这里到底写app logic还是写UI logic，还要受框架开发者用技术手段来限制吗？第二，那如果我要在这个时候写UI Logic怎么办？你原贴是问@BeforeRender干什么，以我目前理解它就干这个。至于为什么要有这样一个回调方法，我第一感觉是“方便”。那hax兄除了“框架即制约”论之外，还有没有其他充分理由去管这事呢？

====思考题解答===

如果你真的认为自己确认这一点，那么请代表写model的java程序员做以下两项思考题：

1. 请想一下，这样的开发模式是谁驱动谁。如果发生表现层的需求变化，会是怎么样的流程。

说了IoVC，就自然是Bean驱动View。目前的做法，如果表现层需求变化，该怎么改就怎么改，尽量不要改id。但如果万一真的有需要改了id，需要通知程序员（如果个人开发就自己去改bean上的绑定）。但你到现在还是没有回答我，前端人员因为什么原因非改id不可。（还是提醒一下，以上做法不强制，如果你的确不爽，或者遇到了某些IoVC实现目前不支持的场景，还是可以在前端写el。毕竟这是个开源项目，目前只是引入IoVC的第一版）

反问一下，标准的开发模式是谁驱动谁？如果发生业务层的需求变化，会是怎么样的流程？

2. 考虑一下，前端人员能否准确告诉你你所关心的那些id？

例如什么场景下他不能准确告诉我我所关心的id呢？他放了个button然后又不知道这是个要用程序支持的东西？那么你为什么认为这同一个前端人员能在这个button里放个正确的el呢？

3. 考虑一下，当页面变更时，前端人员能否记得哪些id是与你有关的，因而不动你的奶酪，或者动了之后能记得通知你。

还是那句，请问前端人员有什么不可抗拒的原因，要动id呢？至少我知道如果在页面写el，有些时候，程序员明明知道这个签名被view用了，但还是不能不变，那他是否记得这个签名是与哪个view有关呢？

4. 页面已经做好，你逐渐添加功能，一切顺利。但是你今天要新加一个功能时，恰巧今天前端人员不在，而你又忘记了他告诉你的那个id名。作为程序员，当你面对页面里成百上千的id时，怎么办。有什么办法消除这类问题？

首先我觉得如果你正确使用jsf而不是故意抬杠的话，页面里出现成百上千个静态id的情况比较少见。前端人员能设计出一个复杂到程序员都看不懂的页面（注意这个页面里基本没有行为逻辑）的情况也不多； 第二还是那句，那如果今天不在的是程序员，那么前端人员对着肯定是成百上千的方法签名，怎么办，有什么办法消除这类问题？如果有个人一定会离开一个月，你作为项目经理，你会希望那个人是前端，于是程序员要自己去看页面id。还是希望那个人是程序员，于是前端人员要去看UML（如果有的话）？

另外，我觉得如果AOM团队经过研究会在以后版本把绑定属性改为非id的话，这些问题会有更好的解决办法。至少到目前我都认为，选用什么属性来做绑定，只是一个实现细节。但是否会改，怎么改（改属性只是目前我这个小脑袋能想到的方案而已），就不是我这个“疑似托”能说了算的了。

很想wicket框架。

个人感觉这种做法不是很好，没有将数据、页面和控制有效的分离。

“那就罗唆一点改为“最多在超出了它目前实现能力那一点”吧。意思能表达到就好。”

随便你怎么表达，结果都一样。事实已经很清楚，IoVC只能在那些过于简化的场景下才能提供一点点方便。如果我一个项目采用了AOM，并用了IoVC，结果必然就会发生同时用el和IoVC绑定的情况。同样性质的事情，却要用两种模式，任何一个有经验的团队管理者肯定都对此嗤之以鼻。

“那么我再把本来的问题问一次：“为什么IoVC直接在java bean中需要绑定的地方打标注，能在模型端享受强类型检查的做法是退化，你的model文件要写个无编译期检查的接口签名还要写个id的做法是进化”？”

请问你，你这里到底检查了什么东西？有什么用？

重复贴一次：

你是不是一并检查一下你的html里的id拼对没有呢？想想吧，这个根本不可能，你怎么知道我写了一个id是为了给你IoVC来侵入的，还是派别的用场的？你的耦合点根本就脆弱不堪。

“当然，如果hax兄精力旺盛有空去为eclipse，netbeans，intellidea等等各种java ide写个这种框架的检查插件，那也是可以的，虽然自己麻烦点，至少用户不会讨厌。但就算这“规约”本身不算一个麻烦，额外增加的麻烦还不只没了编译期检查这么简单。 ”

我如果做产品我当然会提供这样的特性，而不会拿所谓的编译期检查去蒙人——jsp还有类型检查呢。

“我在这里到底写app logic还是写UI logic，还要受框架开发者用技术手段来限制吗？”

不做限制等于鼓励混杂。你一个人图方便可以，如果是一个团队呢。如果所有人都能自觉遵守规定，那我们就一直用jsp好了。

“你原贴是问@BeforeRender干什么，以我目前理解它就干这个。至于为什么要有这样一个回调方法，我第一感觉是“方便”。”

理解力啊。看来我一定要把句子写成大白话：我问的是@BeforeRender在他的IoVC模式中的用途是什么，而不是问它本身干什么。

你第一感觉是方便，我第一感觉是多余！
@BeforeRender对于ui logic来说根本没有什么作用，相反只能是一个混入app logic的后门。

JSF或者任何东西有个什么特性，不代表你就要在所有地方都把这个特性暴露出来。相反，在暴露之前，你应该想清楚，你暴露这个特性给程序员是要起到什么效果，他们会怎么使用，使用会有什么后果。

“说了IoVC，就自然是Bean驱动View。”

那么id是谁说了算？到底谁告诉谁？告诉一个id就可以了吗？
本来前端开发者在知道后端接口之后可以自行组合修改前端表现，现在他要怎么做？

“或者遇到了某些IoVC实现目前不支持的场景，还是可以在前端写el。毕竟这是个开源项目”

我随便最简单的需求他都不支持呢。比如我在页面顶端显示一个分页导航条，低端也显示一个相同的分页导航条，好么，这么简单的需求它居然说id绑定不支持，你用el去吧。那我要你这个鬼IoVC干嘛？说人家el不好不是自欺欺人嘛。
还有，不是看在他开源的份上我还懒得数落它呢。

“只不过框架为你做了这些事情，本质上没区别”？框架是用来干啥的？还不是为快速开发提供便利，如果你喜欢它带给你的便利，那你就用，如果你不喜欢，那也仅仅代表你不喜欢，不用苦口婆心告诉别人，“我不喜欢，你也别用吧”

这个所谓IoVC的主意在我看来是个典型的坏主意。因为它可以应用的场景如hax所言，非常窄。“两个ui control绑定相同的bean"这个问题都解决不了，根本不值得在框架层面为其付出努力，否则在不自觉的情况下引入的隐蔽约束条件将限制整个框架层间的发展。


在Witrix平台中，前台通过标签抽象来绑定字段。因为tpl模板具有强大的抽象能力，所以最特定的情况下可以采用如下做法:
<df:Field name="myAttr" />
对于修改页面，这里显示的是字段的updator, 对于显示页面，这里显示的是字段的inputor. 具体的viewer和inputor在meta中配置，并具有根据数据类型确定的缺省实现。

这里根据字段名来实现绑定，并不需要一个多余的控件id. 这个id仅仅是为了描述限定关系而人工引入的。