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 (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 On Tue, 2008-03-25 at 11:48 -0700, mjovanov wrote: > Hi Simon, thanks for your response. As I mentioned in my original posting, > the Reset button is a command button and is bound to an action listener > method; as I understand, this method is invoked during the > invoke-application phase and it deletes the backing bean, so I don't think I > am bypassing the apply-values phase. I don’t have the immediate attribute on > the Reset button. > > You pose a very good question in the last paragraph: as I understand, what > takes place then is that, in the render-response, JSF is forced to > re-instantiate the backing bean (so that it can provide the state back to > all the components) and this is when a constructor is invoked. This works > for all the other components, which then get their values from the database > except for the text box (the getter is never called!). The only thing unique > about the text box is that is was not rendered in the previous request > (because the radio button had a different value than what’s in the > database). > > > [EMAIL PROTECTED] wrote: > > > > > > On Tue, 2008-03-25 at 08:32 -0700, mjovanov wrote: > >> There is a radio button and a text box on a page. The radio button > >> controls whether the text box is rendered or not. There is also a > >> Reset button, which I have coded to simply remove the backing bean > >> from the session scope thus forcing the constructor to be called > >> (which then loads data from the database). If, however, the value for > >> the radio button from the database calls for the text box to be > >> rendered, I find that the text box is indeed rendered but without any > >> contents, even though there is some in the database. I am guessing > >> this is because JSF after each phase checks whether a component is to > >> be rendered or not and, if it’s not, it then removes all its queued > >> events; as a result, the getter for the value bind to the text box is > >> not called. I wish JSF would not do this…can anyone suggest an elegant > >> solution to this problem? I am using MyFaces 1.1.4 and Tomahawk > >> 1.1.3. > > > > I don't think your analysis is quite right. Queued events can affect the > > update-model and apply-request-values parts of the lifecycle, but I > > cannot think of any events that affect the rendering phase. > > > > During the render phase, components like h:inputText do: > > * if this component has a "submitted value" that was provided during the > > form post, but the update-model did not run, then re-display that > > "submitted value" > > * else evaluate the value expression to fetch a value from the model. > > > > So I suspect what has happened is that you are bypassing the > > apply-values phase for the text box, and so rendering the cached value > > (a blank string). You aren't using "immediate" anywhere are you? > > > > And anyway, if you are deleting the backing bean in an action-listener > > attached to your button (ie during the invoke-application phase) then > > how is the state of your radio-button being passed through to the > > rendered attribute of the textbox? > > > > Regards, > > Simon > > > > > >> > >> ______________________________________________________________________ > >> View this message in context: JSF Lifecycle Question > >> Sent from the MyFaces - Users mailing list archive at Nabble.com. > > > > > > >
