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. > > > -- View this message in context: http://www.nabble.com/JSF-Lifecycle-Question-tp16276003p16285130.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
