Submitted values should not be transient. According to the JSF spec,
they are to be replaced during the decode phase. If the control is
never decoded (like with some use cases using an a4j:region), the
submitted value will never be changed.
The idea of keeping the submitted value around is so that UIInput
controls can re-display the user's selected value when a validation
error occurs.
I think your best bet, is to use binding on that component:
<h:inputText id="theText" value="#{bean.value}" binding="#{bean.text}" />
<a4j:region>
<a4j:commandButton actionListener="#{bean.doit}" reRender="theText" />
</a4j:region>
public class Bean {
private UIInput text;
private String value;
public String getValue() { return this.value; }
public void setValue(String value) { this.value = value; }
public UIInput getText() { return text; }
public void setText(UIInput text) { this.text = text; }
public void doit(ActionEvent evt) {
value = "cleared";
// clear any settings in text:
text.setSubmittedValue(null);
text.setLocalValue(null);
text.setValid(true);
text.setLocalValueSet(false);
}
Now the input text should have a value of "cleared" instead of the
submitted value
-Andrew
On 6/29/07, Michael Heinen <[EMAIL PROTECTED]> wrote:
Hi Andrew,
yes, the control is reRendered and part of the reRendered attribute of
the cancel-button.
If I place a t:outputText with the identical valueBinding before the
t:inputText then the right value is displayed as normal text.
But the inputText contains the old submitted value, which is still set
from the previous request.
I debugged this many times and verified that the old submitted value is
still set and that the corresponding getter is called.
The input component is not in the submitted region because it should not
be validated.
I think this is exactly the problem, that the old submitted value is not
cleared.
But even removing the region from the button and setting ajaxSingle=true
is no alternative.
In this case the wrong date is set again as submitted value (is the user
does not clear it manually)
My actionListener is called but the old view is rerendered containing
all submitted values.
Furthermore I can't create a new viewRoot in the called ActionListener
because ajax would not work in this case and the whole page would be
rerendered instead of just the defined outputpanels.
What about Simon's idea in the previous answer, that submitted value
should be transient ?
Thanks,
Michael
-----Original Message-----
From: Andrew Robinson [mailto:[EMAIL PROTECTED]
Sent: Freitag, 29. Juni 2007 05:59
To: MyFaces Discussion
Subject: Re: how to reset submitted values caused by validation errors ?
Do you have that control in the reRender of the a4j:commandButton tag?
Perhaps you just aren't re-rendering that component?
Also, is that component in the region? If not, then that component
will not be validated and updated, and thus will not have the
submitted value and local values cleared.
-Andrew
On 6/28/07, Michael Heinen <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hi,
>
>
>
> I have a serious conversion/validation problem and don't see any
solution.
>
>
>
> My form contains an inputField for dates and a dateTime converter.
>
> If an invalid format is entered then the submitted value is not erased
and
> the page is rerendered with the entered date.
>
> This is working fine so far.
>
>
>
> Now I execute a kind of cancel button via ajax.
>
> I use an a4j:commandButton with ajaxSingle=true and surrounded this
button
> by an a4j:region in order to process no input fields on serverside.
>
> The value that is bound via valueBinding to the inputField is set to
null in
> the invoked ActionListener.
>
> The problem is now that the old invalid date is rerendered on the
page.
>
>
>
> This happens because the submitted value of the inputField is not null
but
> still contains the old invalid date.
>
> Therefore the valueBinding is not evaluated in the getter.
>
>
>
> I can't set the submitted value to null in the converter because
invalid
> values should be rerendered in case that a normal processing button
(not
> cancel button) is clicked.
>
>
>
> Any help is highly appreciated.
>
> Michael
