Are you not storing your old value on the session? If not, you might look at the x:saveState component.
On Mon, 07 Feb 2005 16:48:24 +0200, Dani Kenan <[EMAIL PROTECTED]> wrote: > 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] > > -- -Heath Borders-Wing [EMAIL PROTECTED]
