Hey Cagatay -
On 6/13/11 3:14 AM, Çağatay Çivici wrote:
> Yes that's right but setValue places the value in state, so it will be
> restored and used in rendering even the users want to use the model
> value to clear it. Instead of making it stateful, if local value is
> set in component instance, that could solve this issue, but I'm not
> sure about if there will be any side effects.
Ah, I see. Thanks for the clarification.
One thing to be careful about: the new JSF 2.1 UIData
"rowStatePreserved" feature relies on state saving to save/restore
row-specific state (including input values). If the goal is to:
1. Avoid cross-request state saving. But also...
2. Not break row-specific state saving
A JSF 2.1-specific option that should work would be to use
TransientStateHelper.putTransient() to store the state (ie. as opposed
to storing it as an instance variable).
(Hrm. Mojarra currently stores the submittedValue as an instance
variable. Not sure how this works with rowStatePreserved.)
Regarding the question of why UIInput relies on state saving for the
"value" attribute, my guess is that this is in part simply due to the
fact that UIInput inherits this behavior from UIOutput. From UIOutput's
perspective, the value attribute should be state saved like any other
attribute. (In the full state saving case, the value attribute needs to
be state saved so that it will be available on post backs. In the
partial state saving case, if the value attribute is modified, this
needs to be recorded as a delta.)
However, in the UIInput case, the value attribute has
significance/semantics that are not present in UIOutput. In particular,
UIInput itself sets the value attribute based on user-specified request
data. This case seems fundamentally different from the case where the
value is set by the application. In fact, this case seems to have much
more in common with the submittedValue case - ie. during input lifecycle
processing, the value attribute is really just a submittedValue that
happened to survive conversion/validation. I don't why we should state
save in one case (value) but not the other (submittedValue). Or, well,
I can see why we do this because it is definitely the easiest solution,
though not necessarily optimal.
In any case, you raise an interesting question: whether there is merit
to state saving user-specified (request-specific) UIInput values across
requests.
Aside from the "reset" use case, another reason that this question might
be worth examining more closely: if we don't need to state save the
value attribute, it would be nice to remove this overhead from/reduce
the size of our partial state saving state.
> Yes for the same reason, immediate can't help here. Frameworks like
> Trinidad created solutions like resetActionListener to overcome this.
> Regarding resetActionListener, it does the job but it traverses all
> the components in tree, what if I want to reset a subtree like a
> children of a panel?
FWIW, I believe Trinidad constrains the reset to the nearest ancestor
tr:subform.
> Sure it could be done by improving the listener but I prefer a "core"
> solution.
>
> In PrimeFaces, we have p:inputText, I'll try my workaround(not keeping
> local value in state) there to see if any problems come up.
I am still confused about this solution… In order to avoid potential
conversion/validation errors when the reset button is clicked, won't you
need to make this button immediate? If so, won't the submittedValue
that gets picked up during decode still mask the newly reset value from
the bean at render time?
Andy