Volker Weber-5 wrote: > > Hi, see inline > > 2008/3/25, simon <[EMAIL PROTECTED]>: >> Hmm.interesting. >> >> In this case, I think your radio-button has absolutely no effect on your >> program (although that still doesn't explain why the textbox is empty). >> >> I believe the process is like this: >> >> on postback: >> (restore view phase) >> * the view (component tree) is restored >> (update values phase) >> * the radio button component pulls its settings from the posted data >> * the textbox component pulls its settings from the posted data >> * the commandButton sees it has been activated and queues an event >> (convert and validate phases apply) >> (update model phase) >> * the radio button updates the backing bean, and clears its >> submitted state >> * the textbox updates the backing bean and clears its >> submitted state > > Here is the problem: the textbox did NOT update the backingBean and > did NOT clear the submitted state because the value of the rendered > attribute evaluates to false after the radioButton has updated the > bean! > > if you switch the order of textbox and radio button it should work as > expected. > > >> (invoke application phase) >> * the queued events are run, causing the backing bean to be deleted >> (render phase) >> * some EL expression causes a new backing bean instance to be >> created >> * the textbox calls the backing bean to check its rendered state [1] >> * assuming the textbox is rendered, it calls the backing bean to get >> the value to render >> * etc for all other components >> >> [1] At this point, the backing bean has completely thrown away the data >> the radio-button set, so the rendered state for the textbox is reset to >> whatever is the default for the backing bean. >> >> Although [1] above is probably not what you wanted, it still does not >> explain the textbox problem. >> >> Questions: >> (1) are you returning a string from the button action listener method, >> or null? Returning a string can cause a fresh view tree to be created. >> You *probably* want to return null here, but in either case I cannot see >> it causing the problem you see. >> >> (2) are you using component bindings anywhere? Bindings can have all >> sorts of odd side-effects, and are better avoided where possible. >> >> (3) is the value setter method for the textbox being called (during the >> apply-values phase)? If it is, then the textbox will definitely be >> clearing its cached "submitted value". If it is not, then that would >> explain the problem - although I cannot see why it would *not* be >> called... >> >> (4) is the method for the textbox rendered property being called *during >> the render phase*? I presume it is, but it might be nice to check.. >> >> Hmm..it just occurred to me that during the apply-values phase, a >> component only pulls data from the submitted form *if it is rendered*. >> Otherwise, it is just a waste of time; the component was never in the >> form so there will of course be no data to fetch from the posted form. >> And it figures out whether it was rendered by evaluating its rendered >> expression. Now there *should* be no conflict with the fact that the >> radio button changes this status, because the radio button only pushes >> its state into the backing bean later (in update-model) but it's >> something to think about. I certainly hope that components do not check >> their rendered state during the "update model" phase... >> >> You might also try to create a very simple webapp that demonstrates the >> problem, then try a more recent myfaces/tomahawk release. >> >> Otherwise, I'm puzzled. Sorry. >> >> >> And by the way, when someone replies to an email with "bottom-posting" >> style, it is a bit rude to then add your comments in "top-posting >> style". It also makes the thread hard to read. >> >> Regards, Simon >> >
First of all let me apologize for the "top-posting", I just didn't know. Hopefully this is a little cleaner now. I took your advice to create a very simple app that demonstrated the problem. To make it easier to read, I have packaged the source files and am attaching them with this post. To see the issue in action, simply click on 'No' and the 'Reset'. Also, notice the second click of the ‘Reset’ button produces the expected results. This seems to clearly show (as both you and Volker Weber-5 correctly point out) the issue is with the fact that, prior to postback, the text box was not rendered and therefore did NOT update the backingBean NOR clear the submitted state during the update-model phase. By the way, switching the order of the components does not fix the problem. I also noticed that adding the readOnly attribute to the textArea fixed the problem, as it forces an invocation of the getter during the render-response phase; however this is clearly not an option in my case. Could this be a bug in MyFaces? http://www.nabble.com/file/p16307571/demo.zip demo.zip -- View this message in context: http://www.nabble.com/JSF-Lifecycle-Question-tp16276003p16307571.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
