>I'm not sure what you mean by 'conversation peice' but I think I >understand what you're saying. The backing bean is in request scope and >renderMode defaults to 'view' if there isn't a request parameter to set >it to something else. So when the form is submitted and the component >tree (re)built, the [EMAIL PROTECTED] will be excluded due to its >rendered property evaluating to false. And that's the reason the model >update doesn't happen?
Yep, that's the idea. >Er, a couple of times :-) Yes, it makes sense; either getDescription() >will be called to render the outputText (view) or it will be called to >render the inputText (edit). And because (without the hidden field) >renderMode is effectively not preserved through the whole 'edit >operation' (initial render and subsequent submit), the inputText gets >replaced with an outputText at the wrong stage. BTW, I have a project that does the whole edit/insert/view mode trick also. Be careful with outputText where @value is set to a request scope EL value. Everything will work until you have a form where validation fails (model is not updated, so output for outputText is nothing.) This is another reason to check out t:saveState. saveState restores during the first phase of the request.
