IoVC，一种新的编程思想

1. 概述

长久以来，在Web编程中，一直很难克服的一个问题就是：展现层与业务数据纠缠在一起，无法进行良好的解耦， 从而造成应用系统的扩展性差，维护成本高。于是，出现了所谓的MVC框架，试图以 Model-View-Control 这种非常流行的设计模式，将两者有效的隔离开来。但回顾目前主流的 Web MVC 架构，它们所做的绝大部分工作无非是：将页面中控件的值取出打包成 Java Bean；再无非就是在帮助你完成页面导航的过程中，辅助你进行页面参数的传递与分析。这样一种“简单 MVC”架构，是无法完全解决“展现层与业务数据完全解耦”这个问题的。 一旦你的需求超越了框架的能力，那么，你将面对的依然是：不得不在展现层中嵌入大量的 Script 代码，可能是Java代码片断，也可能是大量tag-lib及EL表达式的引入。

 

2. 什么是IoVC

IoVC——“Inversion of View-Control”，即“视图控制反转”，换言之：它能够把对“View（即 UI 视图）的控制力”注入到你的后台业务逻辑中。这样一来，你在编写业务逻辑的过程中，对 View 拥有足够的控制力，从而能够将展现层与业务逻辑完全的解耦。

 

举一个场景：页面中有一个文本输入框，它的值对应后台的一个JavaBean的属性。我们首先来看一下传统的编程模型：

 

页面：
<w:textField value="#{myBean.value}"/>
后台：
public class MyBean {
    private String value;
    public String getValue() {
        return value;
    }
    public void setValue(String value) {
        this.value = value;
    }
}

 

此时，假设用户需要发生变化，我们需要设置文本输入框的tooltip，并且，它的值来自于后台 JavaBean 的另一个属性，那么，程序需要做如下调整：

 

页面：
<w:textField  value="#{myBean.value}" tooltip="#{myBean.tooltip}"/>
后台：
public class MyBean {
    private String value;
    private String tooltip;
    public String getValue() {
        return value;
    }
    public void setValue(String value) {
        this.value = value;
    }    public String getTooltip() {
        return tooltip;
    }
    public void setTooltip(String tooltip) {
        this.tooltip = tooltip;
    }
}

 

我们可以观察：在传统的编程模型下，如果页面逻辑发生变化，我们首先需要修改UI展现层，加上 tooltip="#{myBean.tooltip}"　的语句，然后，再在后台Bean中设置此属性值。

那么，在IoVC编程模型下，情况又是怎样的呢？

 

页面：
<w:textField id="txt"/>
后台：
public class MyBean {
    @Bind(id="txt")
    private String value;
}

 

如果需要扩展文本编辑框的tooltip属性，只需要：

 

页面：
<w:textField id="txt"/>
后台：
public class MyBean {
    @Bind(id="txt")
    private String value;

        @Bind(id="txt" att="tooltip")
    private String tooltip;
}

 

在IoVC编程模型下，Web页面不需要发生任何变化，你只需要在后台 Java Bean 中写上这样一行属性声明即可@Bind(id="txt" att="tooltip") private String tooltip，甚至于你连传统的getter/setter都不需要。

 

换言之，在传统的编程模型下，页面美工通过网页设计工具“画”出来的页面，程序员看不懂； 而如果程序员对页面进行修改，则页面美工又无法理解； 并且，如果要更改业务逻辑，程序员需要不断的维护页面内容，最终造成页面美工与程序员无法协同工作。而在 IoVC 的编程思想下，页面美工只需要给每个组件设置一个ID，程序员在后台的业务逻辑中，便拥有对页面 UI 元素的完全控制力。Web页面在美工完成之后，程序员再也无需因为需求的变更或者逻辑的变化，而再重新维护 Web页面内容。

 

简而言之，IoVC是一种更好的MVC，是对MVC的一种高层次抽象。

 

设想一下：日后美工人员画出来的页面（只要设置了正确的ID），程序员可以拿过来直接用，并且， 如果要对页面做调整（只要不是页面元素的增加或删除），程序员可以在自己熟悉的代码中直接设置，这岂非是一种很享受的境界？

 

更多技术文章，请见：http://www.operamasks.org/

 

评论

128 楼 hax 2008-04-01  

我来说点我听来的分析。

按说金蝶也是很强的，当初袁老大一个人实现了j2ee容器，让我等是敬仰不已（这是真心话）。但是Apusic的策略有问题，没有早认识到开源模式，所以上（websphere、weblogic）下（tomcat）受挤压，只能卖给国内一些小企业。当然金蝶自己不靠这个赚钱。
所以现在决定要另辟蹊径。但是找个什么切入点呢？最后就找了JSF。因为一来它是个标准，背靠标准好乘凉，二来JSF因为争议颇多，发展颇慢，所以尚未有人占领市场，三来JSF确实也不能说完全一无是处，还是能够自圆其说的。
怎么推广AOM呢？第一，开源。第二，要宣传我是遵循标准的。企业一般会投资符合标准的产品。第三，要想尽办法搞点特性来吸引开发者。

以上是我听来的。下面是我个人的想法：

为了吸引开发者，就要让开发者觉得它真的方便。看得出AOM在这里下了很多功夫，但是有时候有点走火入魔了，IoVC就是一个典型的没有经过深思熟虑就推出的东西。而且还不小心的夸张为了比MVC更好的MVC，一种新“思想”。

不错如yimlin所说，如果他低调点，提出，我们这样这样干是不是好一点，你们觉得方便不方便等等，那肯定就没有人会来敲打它了。

127 楼 coolyue 2008-04-01  

http://www.operamasks.org/IoVC/index.jsf

我觉得做的蛮好的！

126 楼 xxjhappy 2008-04-01  

yimlin 写道

看了半天！本来不想说！结果发现自己上当了！忍不住了！

所谓IoVC，不过是作者自己的一方意愿！一句话“至于提到历史或者内部原因，我不了解也不想管，反正目前还算挺好用就是了。”让所有参与讨论的人郁闷了！原来不过是人家玩过家家游戏，自己开心！我们去操啥心呢！

好吧， 所谓IoVC（不管叫啥），说是思想就太高了，估计这点让hax很不爽。如果改成在有限条件下的一个实践，我估计hax没有啥意见。毕竟说思想，那就给经的起推敲！很明显所谓IoVC是经不住质疑和推敲的。

没看懂你上了什么当。。。人家hax兄说“AOM选择JSF有非技术原因”，难道我还会天真得去跟一个我不认识的人去探讨一个公司选择一个技术有什么非技术原因吗？他说出来的东西我凭什么就信了？难道他是那个公司的老员工，因为某种原因离开了？又或者推广过某种技术，别人因为某些非技术原因没用他的而用了JSF？猜测这些东西有意义吗？所以关于这些东西，我不了解也不想管。当然，如果他喜欢，不管我想不想管，他都会说，不需要通过我的口来问。。。

125 楼 yimlin 2008-04-01  

看了半天！本来不想说！结果发现自己上当了！忍不住了！

所谓IoVC，不过是作者自己的一方意愿！一句话“至于提到历史或者内部原因，我不了解也不想管，反正目前还算挺好用就是了。”让所有参与讨论的人郁闷了！原来不过是人家玩过家家游戏，自己开心！我们去操啥心呢！

好吧， 所谓IoVC（不管叫啥），说是思想就太高了，估计这点让hax很不爽。如果改成在有限条件下的一个实践，我估计hax没有啥意见。毕竟说思想，那就给经的起推敲！很明显所谓IoVC是经不住质疑和推敲的。

124 楼 xxjhappy 2008-04-01  

2. 语言约束和框架约束还是有所不同的。类型检查出错是违反语言规范。分层不同只是框架开发者和用户的理念不同，或者开发者想象中的场景与用户在实际使用中的场景有所不同而已。

3. 不满意要直接说嘛。。。不能说你不满意它，就把人人都有而你看不爽的特点（例如不提供框架级别的分层限制）去针对它。敲冒头是个人自由，我倒也不反对，但你叫的应该是“谁叫你冒头谁叫你冒头谁叫你冒头谁叫你冒头谁叫你冒头谁叫你冒头”，而不是“谁叫你两个眼睛一个鼻子谁叫你两个眼睛一个鼻子谁叫你两个眼睛一个鼻子谁叫你两个眼睛一个鼻子”

4. 我一开始提到强类型检查是在说你理想框架，既然你说你如果做的话会提供这个特性，其实没什么好讨论的了。

5. 不关我事

6. 所以我说你要先搞明白JSF编程模型

7. 有人在做不等于就不可以做。后发也有先至的，看武功如何了。现在我看国人做东西吧，你做个新的，有人说你冒头；你做个旧的，有人说别人已经做了。你低调吧，有人说你自己都没信心；你高调吧，有人说你口气大。上硬件网站看键盘广告居然还看到有人喷“你的这款键盘是抄袭人家双飞燕的。。。”（硬件的设计你如果没申请专利我有技术可以照做价格还比你低，第三者跳出来喷抄袭真是不知所谓。。。）看来中国人还是什么都别做比较不招骂。至于提到历史或者内部原因，我不了解也不想管，反正目前还算挺好用就是了。

123 楼 likeblood 2008-04-01  

说说我的看法,我们把系统分层的目的无非就是结构清晰,易于扩展和开发维护,MVC也是这样的考虑,如果IOVC能够做到甚至做的更好的话那就是一个好的东西.否则就...

技术是为人服务的,必须要能很好的控制技术在实际中的应用,我不知道这东西就不乱说了,拭目以待好了.

ptw:说实话,要想开发的敏捷,最好的方式就是把层都打破,jsp里直接写sql,如果不考虑以后的话.

122 楼 hax 2008-04-01  

1. 略。
2. 约束，什么叫约束？亏你还整天把强类型检查挂在口边。
3. 它有口气大家当然不满意了，让它多刷牙吧。
冒头未必要敲，但是如果要敲，你总不至于让大家这样，看到IoVC，我们大家一起跳出来狂扁Struts——“叫你丫MVC叫你丫MVC叫你丫MVC叫你丫MVC叫你丫MVC叫你丫MVC……”
4. 你检查的那些东西原来无法检查吗？你新加的id绑定检查还是不检查？你怎么检查？
5. 袁红岗来请我做框架的话，我会考虑考虑。
6. 还是答非所问。
7. 不幸的是这个方向已经有人做了哦。而且AOM选择JSF有不是基于技术的理由的，所以就算是好点子，也不见得会用。嘿嘿。

121 楼 xxjhappy 2008-04-01  

hax 写道

我再说点实际的。我虽然批评IoVC，批评AOM，但是我也没有说他们什么事情都没干对。比如用id绑定的初衷我认为也许是有价值的。但是做法有问题。我认为他还是可以改进的。

1. 明确litebean是用于每个页面的model，而不是业务层所暴露出来的model。不要让litebean有可能一身兼二任，并且要在文档中明确说明litebean不应该做什么。

2. 由jsf来主动选择bind，而不是litebean反向通过id操控。这可以解决我提出的那些所有细节问题。如果你希望有一种方式能够一定程度上控制jsf，就需要改进bind的方式。提示：可借鉴CSS和XBL的设计。但是无论怎样，你需要首先想好你的模式是怎样的，而不是祭出一个无法无天的特性就完事了。

3. 先占位一下。想到再说。或其他同志补充。

1. 这点事实上符合JSF的编程模型，在原理上或者文档上我想AOM都可以这样告诉用户。但“不要让litebean有可能一身兼二任”，个人一来觉得技术上很难做到，二来也没有必要专门去做。

2. 如果你说的“jsf”是指前端页面（例如.xhtml文件）的话，这样做法事实上没有减轻程序员或者前端人员任何一方的负担呀，前端还是要管el，只不过多了个可以重用某个el的特性。但这种重用机会多不多，前端人员是否希望去关心这种重用，我觉得也未必。CSS体现的是内容与展示的分离，这层分离的意义是很明显的。但把el从bind的位置上分离出来而形成一个单薄的间接层，还是由前端人员去管理，目前来看并非很有必要。感觉IoVC的出发点之一在于，把el移到java的层面，让写签名的人去负责绑定，让美工腾出精力来专心设计。

另外，如果“我虽然批评IoVC，批评AOM，但是我也没有说他们什么事情都没干对”的话，我收回上一贴第3点。

120 楼 xxjhappy 2008-04-01  

总算有点新意思了。。。

1. 同感
2. 目前有任何一个现有框架在这么做吗？除了那个虚无飘渺的理想框架。
3. 哦，原来搞了半天你是不满意人家的口气。。。谁冒头你就敲谁吗？
4. 包括但不限于签名拼写。
5. 希望早日见到贵框架面市。
6. 就是普通的JSF生命周期callback的简写形式。
7. 如果这是你基于IoVC的头脑风暴的话，我想AOM团队会考虑的。
8. 哈哈哈哈

119 楼 hax 2008-04-01  

我再说点实际的。我虽然批评IoVC，批评AOM，但是我也没有说他们什么事情都没干对。比如用id绑定的初衷我认为也许是有价值的。但是做法有问题。我认为他还是可以改进的。

1. 明确litebean是用于每个页面的model，而不是业务层所暴露出来的model。不要让litebean有可能一身兼二任，并且要在文档中明确说明litebean不应该做什么。

2. 由jsf来主动选择bind，而不是litebean反向通过id操控。这可以解决我提出的那些所有细节问题。如果你希望有一种方式能够一定程度上控制jsf，就需要改进bind的方式。提示：可借鉴CSS和XBL的设计。但是无论怎样，你需要首先想好你的模式是怎样的，而不是祭出一个无法无天的特性就完事了。

3. 先占位一下。想到再说。或其他同志补充。

118 楼 hax 2008-04-01  

1. 已经说过的话，理解的人自然理解，不理解的人再说也没用。
2. 有些人总喜欢断章取义。我还说过要寻求平衡点，我还说过要解决最主要的问题呐。规约或者约束只是为了保障你的目标而已。如果你能有其他办法（比如你团队的人都是包身工，犯错你就要鞭刑）确保不走偏，那你确实不需要约束。
3. 恭喜你找到了一个struts的问题。这确实是实践中会出现的哦。不过我不敲它是为什么？难道是因为我厚此薄彼吗？非也，只不过本帖是AOM在自吹自擂而已。如果本帖是有人上来自吹自擂struts，我一样会敲——或者我不敲，因为已经太old了，大家已经没有兴趣敲了，偶就歇歇了。所以别拿struts来垫背。
4. “这里没检查什么特别东西，就是普通的java强类型检查而已。”
屁话，我问你检查什么东西，你告诉我就是强类型检查。就好象我问你你今儿早吃啥好东西了，叫我们都吃？你回答说，我就是吃了点普通的好东西，你也吃罢。我ft。
5. “自己写类型检查工具的话，我想具体问问你打算给多少种IDE工具写？”
这是个假设性的问题，而且又是一个只见ide不见实质的问题。不过我还是愿意回答你一下。如果我要写，我打算为0种IDE写，但是同时也是为所有IDE写。没错，就是0，但是也是所有的。认为我在打哑谜？好吧，咱点化一下，每个ide难道都要写一套自己的javac吗？我不打算做可能被绑架的超人，一次做好一件事情足矣。
6. @BeforeRender我已经解释过为什么提这个问题两遍了，但是有些人硬是要认为你丫不懂JSF，那我也没办法。
7. “那么这时，你也可以选择在ManagedBean里绑定组件对象，然后把el直接赋予它的value或bind属性。”
“在生命周期的后续阶段，允许由用户本身或者JSF框架，对组件树进行各种操作，其中自然包括修改组件对象的属性。”
太缺乏想象力了。请看看古老的XMLC吧。
我建议你不如不要写jsf，直接从java构造所有的组件好了。真正的纯粹的IoVC啊！注意，别误会，我不是反讽。我是说真的。它应该让我们直接写swing然后帮我render到web上，多好！
8. 为什么我不再说你所谓“思想”层面的东西了呢？嘿嘿，因为把人IoVC的皮剥一次足够了，没必要剥第二次。你看AOM的人自己都不作声了。我猜他们已经被我点化了，哈哈哈哈。

117 楼 Pylisin 2008-04-01  

思想归思想，我觉得项目或者某产品才能说话，拿出个开源的能说明新思想的DEMO来看看就能说明白了，谈思想和概念的时代已经过去，要和GOOGLE一样，技术推动市场，即便是简单不过的技术，人家用的恰到好处就是成功，就是核心，别走老程序员的死路，别再这里争论，没用，程序的世界不是争论的世界，是证明的世界。小弟一点点见解而已。因为我看了各方发言，发现了心态问题，发现了观望，也发现了关注，但太多的概念和思想还有不确定因素在里面，所以建议楼主DEMO一个不要太简单的东西，那玩意才有份量。

116 楼 xxjhappy 2008-04-01  

现在看来hax兄的焦点已经集中在两点，因为上一贴和上上一贴相比已经没有什么新观点了: 1. 还是那个从第一贴就纠缠至今的问题，一开始叫“你给我把刀子就等于叫我去杀人”论，经过集中讨论，hax兄很大量地说不再追打了，避开锋芒，然后提出了一个换汤不换药的“框架即制约”论。这次hax兄看来是小心得多了。不再跟我探讨着个理论的合理性，而是直接就拿着到处套用了。2. 两个不同id的组件引用同一属性(本质上,是用了同一个el)的问题;

关于“框架即制约”理论，我想我在之前的每一个贴子都有专门讨论过，实在不想和hax兄再纠缠这个东西。如果还有其他读者没有被我们闷跑，顺序看到这里的话，我只想问问目前有哪个实际在使用的框架，是会在其能力允许范围内，人为地加入限制，试图用技术手段限制，来向程序员灌输分层理论的？你遇到这样一个框架，你会不会因为你本来不懂分层，要靠它来学习分层而去选用？在我印象中，分层思路最明确，最严谨的，而又真正试图做过推广的框架，叫做EJB2。现在有多少人在用？有多少人用得开开心心？以致于EJB3专门为了简化编程模型，引入大量的新特性。为了什么？方便，而不是限制。

即使以传统MVC的经典structs为例，它有试图去阻止程序员在Action类中写业务逻辑吗，它有试图阻止我在Action类中直接拼凑html流来响应吗？它只是不推荐你这样做而已。structs事实上提供了方便程序员编写controller层的逻辑，它的设计意图没有涉及view和model，而JSF的设计意图本来就统一了controller与view两层。那为什么structs在controller层与其他层引起的混乱的潜在可能，hax可以视而不见。JSF在model层与controller层引起混乱（也就是在Bean中写业务逻辑）的潜在可能，hax兄就得而诛之。我不想去做太深的猜测，我能想到的最好答案，应该是做前端的hax兄拿着的是UI的锤子，看到任何侵犯其领土的潜在钉子，都本能地要把它敲下去。到目前为止，hax兄随手提出的理想框架，是我所见第一个强调制约的框架，但我已经具体说过，这个框架，为用户，为开发者本身，带来了多少额外的工作量。这还是只从概念上去理解，没有牵涉到实际实现的细节。AOM是一个已经推出的实际框架，hax兄的是一个“我如果做产品我当然会提供这样的特性”的理想框架，也许这就是所谓实践家与理想家的分别。目前以我来说，我只能期待hax兄的新框架早日问世，将全世界引向分层思想的大同了。

这里简单答一下hax兄关于“请问你，你这里到底检查了什么东西？有什么用？”，这里没检查什么特别东西，就是普通的java强类型检查而已。只不过IoVC的框架可以很方便地直接应用IDE或者javac本身提供的类型检查，没有给自己找麻烦。“我如果做产品我当然会提供这样的特性”，如果是指你自己写类型检查工具的话，我想具体问问你打算给多少种IDE工具写？每种工具升级带来的插件冲突你是否维护？答案应该是“我如果做产品我当然会负责维护”。嗯，偷偷告诉你，如果我不写程序去做火箭，现在人类已经登陆火神星了，别让外国政府知道，我怕被绑架。

关于id的问题，关于@BeforeRender的问题。本来我一直在看这个贴子，对于之前一些一看就没用过JSF，完全不了解JSF编程模型，把JSF标准与普通MVC不同的特性归到IoVC头上的贴子，我知道自己即使有针对性地回了也是有心无力的。你不可能叫一个没有用过JSF，但又因为某些原因反对JSF的人，先去了解JSF再和你讨论。所以我第一条回贴，是大而化之地只谈IoVC。谁知hax兄一条逐句反驳的回贴，把大家都绕进去了，不得不涉及到JSF的编程模型时，才发现，原来hax兄不熟JSF。。。那很多问题根本很难展开讨论，如果hax兄真的有心情讨论这些问题，我建议还是先去搞清楚JSF的编程模型，然后我们再来讨论吧。

下面的话是和有兴趣了解AOM和JSF的朋友说的。

关于相同属性绑不同组件的问题，首先我觉得AOM不会阻止你走回老路直接在页面写el，但的确如hax所说，会在系统中引入造成两种不同风格的写法，至于这种做法的破坏性有多大，我是没有看出来，但事实上总会有人看到星星火苗，就联想到山林大火。那么这时，你也可以选择在ManagedBean里绑定组件对象，然后把el直接赋予它的value或bind属性。这种做法，IoVC本身只帮你绑定了组件，并没有自动根据属性创建el，el还是要自己写。（但反正就算不用IoVC也是要在页面里写el，工作量并没增加多少）

但一写到这里，我就觉得有人就会跳出来：“慢，你这叫attribute侵入，你们AOM提倡这样的写法，没有想过它的破坏性吗！”对于这个问题，我觉得这个人是既不了解JSF的编程模型，又不了解侵入。在JSF编程模型中，组件树是前端页面组件在服务器端一个映射，这个组件树在请求生命周期的第一阶段restore view中被创建出来，对应着提交请求时前端页面的组件状态。在生命周期的后续阶段，允许由用户本身或者JSF框架，对组件树进行各种操作，其中自然包括修改组件对象的属性。最后，在render response阶段，JSF框架再根据组件树创建响应信息（在http协议中，就是html页面了），然后响应信息被整个返回给客户端。这套编程模型是JSF的标准编程模型，也许与很多人心目中的MVC有差别，但是我在这里只能先给大家一个整体印象，JCP既然把它作为一个规范提出来，作为JavaEE5的重要特性之一，至少在编程模型上，它是能自圆其说的。关于侵入，我没理解错的话，应该是ajax出现之后的一个概念，说的是你在客户端发起一个ajax请求，然后前端js逻辑本来是打算将此响应赋予attribute，但程序逻辑将返回的响应信息作为javascript来执行了，或者是该attribute在前端渲染时浏览器会将其内容作为脚本执行，视为脚本侵入。这种做法据说是会造成很多问题，包括安全性，也包括编程模型（如果你故意利用这种特性来作为程序正常逻辑的话）。但这和JSF里一次性将组件树渲染为html响应发送回去的做法是完全不同的两件事。

但如果所谓的“attribute侵入”，是指所有在服务器端逻辑试图对显式改变（即使用el绑定，其值也是由Bean去决定的，只不过框架隐含完成了这个动作而已）组件属性的行为。那么这个问题也象上面关于JSP里用jdbc一样，不要跟AOM说，请写信给JCP讨论。。。当然，如果有人不吝赐教的话，我是很想了解一下这样做具体有何不妥，但希望讲述的人至少应该先熟悉JSF的编程模型。

经过连日来与hax兄的讨论，我觉得到目前为止我的观点基本上已经说明了。hax兄从一开始的“展示比业务易变”（最后结果：你自己去问袁红岗），到后来的“id易变”（最后结果：我懒得回答），到后来的“给我把刀子我就会去杀人”（最后结果：不再追打，换成了框架即制约的提法），到后来的“程序员需要引导”（最后结果：被忽略），再到后来的“框架即制约”（最后结果：没有讨论，直接套用），这些真正在“思想”层面与IoVC相关的问题，我觉得也已经做了充分的讨论。问题纠缠在用id绑还是用什么其他属性来绑，两个组件绑同一个属性时在bean里赋值el妥不妥这些实现细节问题，我觉得还是应该hax兄真正了解了JSF的编程模型后才有讨论的基础。因此如果没有什么新的论点的话，我觉得可以到此为止了，毕竟我的职业是写程序，不是在论坛上纠缠一些反反复复的问题。

115 楼 i_love_sc 2008-04-01  

根本不符合解耦和的原则。典型的反模式。等于把html传播到model层。
再说了，现在web交互的要求日益提高，如果只是提升这点功能话，根本无关紧要。页面的事情应该让它自己作主。

114 楼 canonical 2008-03-31  

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


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

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

113 楼 anakin1978 2008-03-31  

jameswxx 写道

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

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

112 楼 hax 2008-03-31  

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

随便你怎么表达，结果都一样。事实已经很清楚，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不好不是自欺欺人嘛。
还有，不是看在他开源的份上我还懒得数落它呢。

111 楼 ske3 2008-03-31  

很想wicket框架。

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

110 楼 xxjhappy 2008-03-31  

...大家好好的讨论技术，干嘛要想骂人呢，有话好好说嘛。至少我觉得技术论坛讨论技术问题，出发点是，第一，帮助自己理清思路（在与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的话，这些问题会有更好的解决办法。至少到目前我都认为，选用什么属性来做绑定，只是一个实现细节。但是否会改，怎么改（改属性只是目前我这个小脑袋能想到的方案而已），就不是我这个“疑似托”能说了算的了。

109 楼 hax 2008-03-31  

没空也没兴趣在这里给连反问句和归谬法都看不懂的人上逻辑和语文课，偶也不想骂人，俺毕竟不是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时，怎么办。有什么办法消除这类问题？