[EMAIL PROTECTED] wrote:
>
> Volker Weber schrieb:
>> 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.
>>
> Yep, I've checked the code and to my surprise Wolker is right.
>
> In Myfaces 1.2.2 at least, UIInput.processUpdates does indeed call
> isRendered()
> again before updating the model and clearing its submitted value.
>
> It seems to me that behaviour is wrong. Components should call
> isRendered during processDecodes, but then remember that state until
> after the invokeApplication phase. That would (a) solve problems like
> this one, and (b) avoid multiple evaluations of isRendered. Of course
> the spec would need to be carefully checked to make sure such an
> implementation is compliant with the spec wording. And anyway, I doubt
> this change would get high priority..
>
> Back to the original problem: if swapping the order of the components in
> the page is not possible, then a workaround might be to attach a
> ValueChangeListener to the radio-button which looks up the textbox
> component by id (relative to the radio button component) and manually
> resets its submittedValue to null. Or something like that.
>
> Regards,
> Simon
>
>
That did it, thank you very much! Sorry, I didn't see your message before
creating a sample demo app and posting my last message.
Just so I understand this correctly: why exactly does resetting the
components submittedValue to null force the getter to be called during
render-response? I mean, shouldn't that happen anyway?
--
View this message in context:
http://www.nabble.com/JSF-Lifecycle-Question-tp16276003p16315410.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
