Dennis Byrne wrote:
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.
Well the way things are setup now, the backing bean is request scoped
but any output data generally gets loaded from the database at the start
of the JSF life-cycle (using init() in a Shale ViewController).
So, in cases where I need to output something, I know I'll have it
there. Isn't what you're talking about only an issue if I go from a view
with an input component to one that expects to display the input value,
rather than validation returning to the same view that has the input
component?
Not sure I follow what the gotcha is...
L.
