[EMAIL PROTECTED] schrieb:
Hi,
I keep running into a problem where the setter of a field (say/ Field
1/) in my backing bean (in request scope) that is rendered
conditionally is not called.
I think what happens is that Trinidad evaluates the rendered condition
to determine if the setter should be called. My backing bean is sort
of stateless and needs to be filled with data from the form.
Because the condition depends on another field (/Field 2/) in the
backing bean, the outcome of this evaluation will only be correct if
the setter of Field 2 was already called, which may or may not be the
case. So for some fields it will work but for other it will not.
How can I get around this?
It is standard behaviour for JSF components to evaluate their "rendered"
expression, and NOT write to the "value" property if rendered is false.
This is nothing to do with Trinidad.
If you have a view where the rendered property of a component depends
upon the user-provided value of another field, then I don't think that
is going to work. I wouldn't think it even depends on component order in
the page; an EL expression uses only values that have already been
pushed into the model, but a component uses the "rendered" state to
determine whether to accept data from the posted form in an earlier
phase, ie before any values are pushed to the model.
See specification/javadoc for methods UIComponent.decode and
UIComponent.processDecodes.
I can't think of any solution for this. And I don't really understand
why you are trying to do this either. You are trying to switch the
"rendered" state of a component in the middle of the postback phase.
Why? JSF really expects the rendered state during postback to match the
rendered state that existed during the earlier render phase.
As a side-point, does the JSF spec actually say that "rendered" EL
expressions should be re-evaluated during postback? That's what MyFaces
currently does, but it seems to me that the true/false state should
really be part of the component's saved state and the restored value
simply used during postback (and recalculated in render phase). That
doesn't make any difference to the original question however.
Regards,
Simon
