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