Проверка JSF AJAX: execute = "@ this" render = "@ form" несовместимо в зависимости от предыдущих запросов - PullRequest
7 голосов
/ 09 декабря 2011

У меня есть h:commandLink, который вызывает метод, который изменяет свойство, привязанное к радиовходу.

У меня также есть текстовый ввод в той же форме с некоторой проверкой (обязательно = true).

Если я оставлю ввод текста пустым и нажму h:commandLink с execute="@this, переключатель будет обновляться из свойства модели, как и ожидалось, поскольку ввод текста никогда не обрабатывается и проверка никогда не запускается.

Однако, если я сначала нажму на другую h:commandLink с execute="@form", , а затем ссылку с execute="@this", сообщения проверки исчезнут, но значение переключателя не будет , а не обновить модель, хотя UIInput для переключателя никогда не находился в недопустимом состоянии.

Меня раздражает, что execute="@this" ведет себя по-разному в зависимости от того, что я делал ранее, когда моим намерением с @this было заставить все обновляться из модели и игнорировать любые отправленные значения из компонентов.

Я подозреваю, что происходит что-то вроде этого:

  • с @form, оба переключателя и текст обрабатываются.
  • Радиокнопка действительна, поэтому localValue установлен
  • Фаза проверки процесса в целом завершается неудачно из-за неправильного ввода текста, поэтому localValue остается установленным и не очищается и не распространяется на value
  • единственный выход из этого - явный вызов resetValue() или повторная обработка рассматриваемого компонента (например, execute="@this radio") для очистки localValue, а затем разрешение обновления из bean-компонента.

Мои вопросы:

  • верно ли мое понимание жизненного цикла?
  • Я что-то не так делаю, или это одна из неприятных вещей в JSF?

Такое ощущение, что это может быть просто еще одним примером этого вопроса

Как заполнить текстовое поле с помощью PrimeFaces AJAX после возникновения ошибок проверки?

К сожалению, я чувствую, что нахожу много таких в последнее время. : - (

Пример кода ниже:

<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>

И этот боб:

@ManagedBean
@ViewScoped
public class TestBean {

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

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

1 Ответ

6 голосов
/ 10 декабря 2011

верно ли мое понимание жизненного цикла?

Да.


Я что-то не так делаю, или это одна из раздражающих вещей JSF?

Это одна из "раздражающих вещей" JSF. Как указано в моем ответе на этот связанный вопрос:

Возвращаясь к конкретной проблеме, я бы предположил, что это упущение в спецификации JSF2. Нам, разработчикам JSF, было бы гораздо больше смысла, когда спецификация JSF предписывает следующее:

  • Когда JSF необходимо обновить / повторно обработать входной компонент с помощью запроса ajax, и этот входной компонент не включен в процесс / выполнение запроса ajax, тогда JSF должен сбросить значение входного компонента.

Я больше не помню, если я когда-либо сообщал об этом против спецификации JSF. Изменить: я сообщил об этом: JSF spec проблема 1060 .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...