JSF AJAX validation: execute=“@this” render=“@form” inconsistent depending on prior requests

Question

I have an h:commandLink that calls a method that changes a property bound to a radio input.

I also have a text input on the same form with some validation (required=true).

If I leave the text input blank, and click on h:commandLink with execute="@this , the radio button updates from the model property as expected, because the text input is never processed and validation never fires.

However, if first I click on a different h:commandLink with execute="@form" , then the link with execute="@this" , the validation messages go away but the radio button value does not update from the model even though the UIInput for the radio button was never in an invalid state.

I'm finding it annoying that the execute="@this" behaves differently depending on what I had done previously, when my intent with @this was to force everything to update from the model and ignore any submitted values from the components.

I suspect what's happening is something like this:

• with @form , radio button and text are both processed.
• Radio button is valid so localValue is set
• Process validations phase fails overall because of invalid text input, so localValue remains set and does not get cleared or propagate to value
• the only way out of this is to explicitly call resetValue() or to re-process the component in question (eg, execute="@this radio" ) to clear out localValue and then allow refreshing from bean.

My questions are:

• is my understanding of the lifecycle correct?
• Am I doing something wrong, or is this one of the annoying-by design things about JSF?

It feels like this may just be another example of this question

How can I populate a text field using PrimeFaces AJAX after validation errors occur?

Unfortunately I feel like I'm finding lots of those lately. :-(

Code example below:

<h:form>
<h:messages/>

Radio = 
<h:selectOneRadio value="#{testBean.radioValue}" id="radio" binding="#{radio}">
    <f:selectItem itemValue="foo" itemLabel="Foo"/>
    <f:selectItem itemValue="bar" itemLabel="Bar"/>
</h:selectOneRadio>

<br></br>
radio bean value = <h:outputText value="#{testBean.radioValue}"/>
<br></br>
radio UIInput localValue = <h:outputText value="#{radio.localValue}"/>
<br></br>
radio UIInput value = <h:outputText value="#{radio.value}"/>

<br></br>

String w/validation = <h:inputText value="#{testBean.stringValue}" required="true" />

<br></br>

<ul>
<li>
<h:commandLink actionListener="#{testBean.changeRadioValue}" value="execute = @form">
    <f:ajax render="@form" execute="@form"/>
</h:commandLink>
</li>

<li>
<h:commandLink actionListener="#{testBean.changeRadioValue}" value="execute = @this">
    <f:ajax render="@form" execute="@this"/>
</h:commandLink>
</li>

    <li>
<h:commandLink actionListener="#{testBean.changeRadioValue}" value="execute = @this radio">
    <f:ajax render="@form" execute="@this radio"/>
</h:commandLink>
</li>   
</ul>

</h:form>

And this bean:

@ManagedBean
@ViewScoped
public class TestBean {

private String radioValue = "foo";
private String stringValue;

public void changeRadioValue() {
    radioValue = "bar";
}
 // + getters/setters
 }

Answer 1

is my understanding of the lifecycle correct?

Yes.

---

Am I doing something wrong, or is this one of the annoying-by design things about JSF?

It's one of the "annoying by-design things" of JSF. As stated in my answer on that related question:

Coming back to the concrete problem, I'd imagine that this is an oversight in the JSF2 specification. It would make much more sense to us, JSF developers, when the JSF specification mandates the following:

• When JSF needs to update/re-render an input component by an ajax request, and that input component is not included in the process/execute of the ajax request, then JSF should reset the input component's value.

I only don't remember anymore if I have ever reported this against JSF spec. Edit: I reported it: JSF spec issue 1060 .