jsf 中的 immediate 很烦阿，今天有发现它的一个特性，一般情况下在 jsf生命周期的第6步RENDER_RESPONSE，会调用get方法来完成页面的显示，而如果这个生命周期是由一个 immediate＝true 的组件引发的而且是针对同一页面的话，get方法就不会执行。利用这点终于解决了一个问题，不过这是在 portlet下的，而且是a4j的组件，不知道原生的jsf是不是一样。
今天想想可能真的是ajax的原因。而不是jsf 中的 immediate 的特性。
页面 上的 输入组件 的输入值 如果是 null 时（组件的required=false），如果 组件的值是原始类型，页面自然 会出错（converter出错）。 否则 组件的值是对象类型的话，组件的验证器 不会 执行（实验中 自定义的验证器没有执行）。 就是说 在验证器里 对null的情况 是没有办法处理的。
今天看到一个网站上的一个有关jsf中的immediate的讨论，一般我们都会认为对于command...和inputinput...immediate的处理是不同的，但有一个人认为其实他们都是相同的，不同的是对于command来说action会提前调用（先于validator）,因为action的导航作用才使得页面跳过了后面的验证。听起来有些道理，我特地实验了一下，就是去掉action的返回值，结果证明他的观点是错误的。
今天看core javaserver faces终于知道了原因，因为所有action，不论immediate=true 或者false，都会直接调用Render Respo ...
作为输入组件，如UInput, immediate="true"时验证会提前，不过我感觉这好像没什么用，因为本来第三步就会执行验证了,提不提早都一样。它的另外一个效果是valueChangeListener会先于第三步process validate 验证执行，这点倒是满有用的。而一般情况下valueChangeListener会在值改变并且通过验证之后即invoke applications阶段才执行，当然会先于action执行的。
评论排行榜