Matthias, When in doubt, check the source. Take a look at RendererUtils.getStringValue(). If the object is an EVH, and it has a submitted value during the render response phase, the method returns that string to be rendered.
The reason you're seeing the behavior described below is because the submitted value isn't set on the first rendering phase, and the submitted value is set on the second rendering phase. Instead of trying to disprove the behavior by setting a component value or backing bean model, change your code to prove the described behavior by setting the component's submitted value instead. Or set a breakpoint on RendererUtils.getStringValue(). Just remember that JSF will set the submitted value on the component to null if the value can be successfully converted and validated. That happens during apply for components marked immediate=true and during process validations for components marked immediate=false. On 11/29/05, Matthias Kahlau <[EMAIL PROTECTED]> wrote: > Hi! > > Thanks for linking to the interesting JIRA comments on the rendering > behavior of input components in > http://issues.apache.org/jira/browse/MYFACES-749, but I think JSF must work > a little different from what is described in the comments: > > >The thing is, as Mike explained further up in his post, that an input > component renders its "submitted value" out to the page if this submitted > value is not null. > > >So what you would need to do is to reset the submittedvalue in the > valueChangeListener. > > > I have experienced a different behavior: > > - I set the ValueBinding property of the inputText before the page is > displayed to AAA > - The page is displayed with inputText showing AAA > - The page is submitted with a selectOneRadio calling submit() if an onclick > event is fired > - The value change listener method of selectOneRadio is invoked in the Apply > Request Values Phase (immediate is true) > - I change the ValueBinding property of the inputText to BBB in the value > change listener method > - The page is redisplayed with the inputText showing BBB (component renders > NOT its submitted value (AAA), but the new ValueBinding property value BBB) > - The page is submitted again with a selectOneRadio calling submit() if an > onclick event is fired > - The value change listener method of selectOneRadio is invoked in the Apply > Request Values Phase (immediate is true) > - I change the ValueBinding property of the inputText to CCC in the value > change listener method > - The page is redisplayed with the inputText showing still BBB (now, the > component seems to render its submitted value (BBB), but the new > ValueBinding property value CCC) > > -> It seems that the inputText renders the submitted value only after the > second submit?! > > > Regards, > Matthias > > > -----Ursprüngliche Nachricht----- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Auftrag > > von Mike Kienenberger > > Gesendet: Montag, 28. November 2005 16:19 > > An: MyFaces Discussion > > Betreff: Re: What is responsible for component value update in the > > render response phase? > > > > > > Take a look at the last two comments in > > > > http://issues.apache.org/jira/browse/MYFACES-749 > > > > Basically, you should be able to guarantee this change if you directly > > set the component's submitted value. This will override any other > > values (the component's local value and the component's backing bean > > value). > > > > On 11/28/05, Matthias Kahlau <[EMAIL PROTECTED]> wrote: > > > Hi! > > > > > > > > > I can see in the MyFaces logging output that the getter methods of some > > > ValueBinding variables are called to update the component > > values. But not > > > all possible getter methods are called, so what's responsible for that? > > > > > > I would like to update the value of an inputText field in a value change > > > listener method, but the component value is not updated in the render > > > response phase in some cases, so the assignment to the > > ValueBinding variable > > > is not reflected in the inputText field. > > > > > > > > > > > > Regards, > > > Matthias > > > > > > > >
