You are completely right. However, for the sake of argument, you should know that the problem is manifested in ALL input component due to the responsible code residing in UIComponent.validate() which all subcomponent are required to call using super.validate() according to the javadoc.
So this solution cannot be considered even as a temporary workaround, as I might end up inheriting every component I use. > -----Original Message----- > From: Heath Borders [mailto:[EMAIL PROTECTED] > Sent: Monday, February 07, 2005 4:04 PM > To: MyFaces Discussion > Subject: Re: Serious inherent problem with the JSF framework life cycle > and value binding handling? > > Just for the sake of argument, you could extend the renderer for > whichever component is giving you the trouble, and change its > encode/decode behavior so that it saves the value in its attributes > map. > > > On Mon, 07 Feb 2005 11:25:18 +0200, Dani Kenan <[EMAIL PROTECTED]> > wrote: > > > > > > > -----Original Message----- > > > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > > > Sent: Monday, February 07, 2005 3:01 AM > > > To: MyFaces Discussion > > > Cc: Sean Schofield > > > Subject: Re: Serious inherent problem with the JSF framework life > cycle > > > and value binding handling? > > > > > > On Mon, 07 Feb 2005 02:46:05 +0200, Dani Kenan > <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > It seems quite clear that change event handlers cannot be used > together > > > with > > > > value properties bound to request scope beans, since they will > always be > > > > invoked. > > > > > > JSF promises to keep the expressions for all value binding expressions > > > that you have set, plus values that you have set directly (not using > > > value bindings). If you are expecting the framework to keep the > > > values that your VB expressions point at, you are expecting something > > > beyond what is promised. > > > > [Dani Kenan] My only expectation is that the value change listener fires > > only when the value changes. Is that too much to ask? > > > > How this is implemented is not the issue. I did not request the > framework to > > keep the value that VB expressions point at. In any case even if this is > > required in order to fix the way change events are determined, it can be > > kept and regarded as an implementation detail and not exposed as a > general > > feature of the framework. > > > > The spec reads: > > > > "2.5.1.3 Executing Validation > > ... The converted value is pushed into the component's setValue() > method, > > and a ValueChangeEvent is fired if the value has changed." > > > > There is nothing in the spec which prevents a fix. It's a matter of > > interpreting what "value has changed" means. I suggest the intuitive > > interpretation: changed between the last and current requests. > > > > > > > > If you want to use value change events and request scope backing > > > beans, you should bind the *component* into the backing bean instead > > > of the *value*. This would cause the following adjustment to your > > > initial example: > > > > > > <h:selectOneMenu id="typeName" > > > binding="#{typeListPage.typeName}" > > > valueChangeListener="#{typeListPage.onChangeTypeName}"> > > > <f:selectItems value="#{typeNameSelectItems}" /> > > > <h:selectOneMenu> > > > > > > with the following property in your bean that "typeListPage" points > at: > > > > > > private HtmlSelectOneMenu typeName = null; > > > > > > public HtmlSelectOneMenu getTypeName() > > > { return this.typeName; } > > > > > > public void setTypeName(HtmlSelectOneMenu typeName) > > > { this.typeName = typeName; } > > > > > > In this scenario, JSF saves the value of the component across requests > > > (and restores the component reference by calling setTypeName() during > > > Restore View phase, so that value change events only fire if the value > > > actually changes, as you expect. > > > > > > If you use value binding expressions, it is your application's > > > responsibility to maintain the appropriate state. > > > > > > Craig McClanahan > > > > [Dani Kenan] Doesn't this means that for request scoped beans with event > > handler the model we must follow is that of ASP.NET? > > > > Jsf allows you to bind to model elements (value binding) and to ui > > components (component binding) where as ASP.NET allows only its version > of > > component binding, pumping the values between the components and a model > is > > the developer's job. This results in many ASP.NET applications not > having a > > backing model at all (and I am talking about complex applications that > > should have used one). > > > > I liked jsf idea of binding to the model better. It would be regretful > if it > > becomes less usable due to this limitation. > > > > You suggest resorting to control binding whenever a change listener is > > needed. However, this results in some of the ui tree components being > > updated automatically and others manually. This inconsistency leads to > less > > clean design and much less readable code. > > > > Developers with consistency in mind might feel better off using > component > > binding all along (ignoring the possibility of value binding) - thus > follow > > ASP.NET paradigm and end up with the same pitfalls. > > > > Another reply to my post by Sean Schofield suggested I dump the change > > listeners and use the life cycle events in a framework like Struts Shale > > (which I suspect you are quite familiar with...) to determine changes > and > > populate model elements on my own. > > > > Sean's solution is viable and preserves consistency. And I liked what > Struts > > Shale has to offer without regard to the value change issue (isPostBack > flag > > and prerender event to start with). > > > > Never the less, I still cannot see why I must either move my beans to > the > > session, or bind to controls and not the model, or neglect event driven > > programming all along in order to fix this issue of "value change events > > fire without any reason". > > > > Dani Kenan > > > > > > > -- > -Heath Borders-Wing > [EMAIL PROTECTED]
