Отладка жизненного цикла JSF - что именно происходит на каждом этапе

Я решил полностью копаться в JSF 2.0, так как мой проект требует глубокого знания. Я читаю JSF Lifecyle Debug, хорошо написанную и потрясающую статью о жизненном цикле JSF. Читая эту статью, у меня есть следующие недоумения.

  • Если это начальный запрос, в Restore View Phase создается пустой вид и выполняется прямая Render Response Phase. На данный момент нет состояния для сохранения. Что на самом деле происходит в Render Response Phase, то? Я немного смущен, пока я запускаю пример.

  • В статье говорится, что полученное входное значение устанавливается в фазе inputComponent.setSubmittedValue() в Apply Request Values. Если выполняется проверка и преобразование, значение устанавливается в inputComponent.setValue(value) и inputComponent.setSubmittedValue(null). В одной и той же статье указывается, что теперь, если в следующем запросе обратной обратной связи значение изменяется, оно сравнивается с представленным значением, которое всегда было бы нулевым для каждого сообщения, v alue change listener будет вызвано. Это означает, что если мы не изменим значение даже, поскольку представленный Value будет null, valueChangeListener всегда будет вызываться? Я смущен этим утверждением. Может ли кто-нибудь уточнить это?

  • В статье указано использование атрибута immediate. Если атрибут immediate установлен на входном компоненте, то в идеале Process Validation Phase пропускается, но все преобразования и проверки происходят в Apply Request Values. Моя точка зрения заключается в том, что все еще, когда происходит преобразование и проверка, какое преимущество пропускает третья фаза?

  • Что означает значение, полученное термином?

  • Я хотел бы знать, если можно сказать, что в представлении есть пять полей. Содержит ли JSF список некоторых наборов этих значений и Apply Request Values и Process Validations перебирает по очереди один за другим?

  • В последнем пункте этой статьи, где указано, когда использовать атрибут immediate. В соответствии с моим пониманием, если непосредственный атрибут установлен как в компоненте ввода, так и в командном компоненте, он будет пропускать фазы из значений запроса заявки для вызова приложения для любого атрибута, не имеющего immediate. Затем, что последнее выражение означает кнопку "забытый пароль" в форме входа в систему с обязательным и немедленным полем имени пользователя и обязательным, но немедленным полем пароля.

Я знаю, что это очень простые путаницы, но ясность в этих вопросах, безусловно, поможет обострить знания JSF.

Ответы

Ответ 1

1: что на самом деле происходит в фазе ответа рендера?

Создание HTML-вывода для клиента, начиная с UIViewRoot#encodeAll(). Вы можете увидеть результат с помощью rightclick, View Source в webbrowser (и, следовательно, NOT с помощью rightclick, Inspect Element в webbrowser, так как это будет отображать только дерево HTML DOM, которое веб-браузер создавал на основе исходного исходного кода HTML и всех последующих событий JavaScript).

2: он сравнивается с представленным значением, которое всегда было бы нулевым для каждого сообщения назад

Нет, он удерживается как переменная экземпляра. JSF не вызывает getSubmittedValue() для сравнения.

3: Моя точка зрения заключается в том, что все еще, когда происходит преобразование и проверка, какое преимущество пропускает третья фаза?

Об этом говорится в нижней части статьи под Хорошо, когда следует использовать непосредственный атрибут?. В двух словах: определение приоритетности валидации. Если компоненты с immediate="true" не выполняются при преобразовании/проверке, тогда компоненты без immediate="true" не будут преобразованы/подтверждены.

4: Что означает значение, полученное термином?

"Необработанное" значение, которое отправил enduser (точное входное значение, которое конечный пользователь внес в форму ввода). Обычно это String. Если вы знакомы с сервлетами, то легко понять, что это точно значение, которое вы получаете по request.getParameter().

5: Содержит ли JSF список некоторой коллекции этих значений и факулы запроса запроса и проверки процесса обрабатывают по очереди один за другим?

Почти. Коллекция уже присутствует в аромате дерева компонентов JSF. Таким образом, JSF в основном выполняет итерацию по древовидной структуре, начиная с FacesContext#getUIViewRoot().

6: Тогда, что последнее утверждение означает кнопку "забытый пароль" в форме входа в систему с обязательным и немедленным именем пользователя и требуемым, но немедленным полем пароля.

Таким образом вы можете повторно использовать форму для входа в "забытый пароль" . Если вы отправляете кнопку "Войти", то, очевидно, должны быть подтверждены как поля имени пользователя, так и пароля. Однако, если вы отправляете кнопку "забытый пароль" , тогда поле пароля не должно быть проверено.

Таким образом, вы можете найти приведенную ниже диаграмму JSF/жизненный цикл, полезную для быстрой справки:

  • fc = FacesContext
  • vh = ViewHandler
  • in = UIInput
  • rq = HttpServletRequest
  • id = in.getClientId(fc);

1 RESTORE_VIEW

String viewId = rq.getServletPath();
fc.setViewRoot(vh.createView(fc, viewId));

2 APPLY_REQUEST_VALUES

in.setSubmittedValue(rq.getParameter(id));

3 PROCESS_VALIDATIONS

Object value = in.getSubmittedValue();
try {
   value = in.getConvertedValue(fc, value);
   for (Validator v : in.getValidators())
      v.validate(fc, in, value);
   }
   in.setSubmittedValue(null);
   in.setValue(value);
} catch (ConverterException | ValidatorException e) {
   fc.addMessage(id, e.getFacesMessage());
   fc.validationFailed(); // Skips phases 4+5.
   in.setValid(false);
}

4 UPDATE_MODEL_VALUES

bean.setProperty(in.getValue());

5 INVOKE_APPLICATION

bean.submit();

6 RENDER_RESPONSE

vh.renderView(fc, fc.getViewRoot());

См. также: