Как разные фазы жизненного цикла JSF ведут себя в представлении без состояния, содержащем форму

Если у меня есть вид без атак в JSF, содержащий форму. Как будут действовать разные этапы, когда я заполню форму и отправлю ее? так как состояние представления не хранится нигде, как теперь будут работать этапы "значения запроса appy", "модель обновления" и т.д.?

Ответ 1

Все этапы жизненного цикла JSF будут продолжать работать. Только фазы просмотра восстановления и рендера будут вести себя по-другому. Фаза восстановления будет теперь создавать только представление, но не восстанавливать его состояние. Фаза ответа рендеринга теперь отображает только представление, но не сохраняет его состояние. Это в основном это. Все остальные фазы ведут себя точно так же.

Для разработчика главное отличие в том, как будет вести себя @ViewScoped beans. Они будут в представлениях без гражданства вести себя точно как @RequestScoped beans. Поэтому вы просто сделаете их @RequestScoped сразу. Кроме того, любые программные изменения в состоянии дерева компонентов не будут сохранены для обратной передачи, но разработчики не должны программно манипулировать деревом компонентов в любом случае (например, binding, findComponent() и т.д.), Что все просто подозрительно).

Просто обрабатывайте такую ​​форму, как если бы вы могли использовать ее только с @RequestScoped bean. Если вы привязываете условные атрибуты, такие как rendered, disabled и readonly к свойству bean и меняете его с помощью ajax на одном и том же представлении, тогда вам нужно убедиться, что вы повторно инициализируете тот же bean свойства (читайте: просмотреть область действия) во время bean @PostConstruct. JSF именно в качестве части защиты от взломанных запросов повторно проверяет их перед применением значений запроса. Один из способов - передать их через скрытые поля ввода и вручную извлечь в качестве параметров запроса (вы в основном заново изобретаете то, что сделал javax.faces.ViewState). Но вы должны понимать, что это открывает возможности для хакеров манипулировать ими. Это особенно вредно, если, например, условный отрисовка только командной кнопки администратора становится зависимой от простого параметра запроса, а не от состояния представления JSF таким образом (преувеличенный пример, но он должен дать изображение).

См. также: