Interceptor
В этой части мы завершаем рассмотрение примера с авторизацией пользователя. Нам нужно учесть, что когда пользователь авторизовался, то система должна запомнить этого пользователя. Дальнейшие действия (экшны) будут обрабатываться с учетом того, что пользователь уже авторизован.
Если же данные пользователя не найдены, только тогда предложить ему ввести их (перенаправить действие на login.action).

Замечание: Для простоты мы будем хранить пользователя (объект) в http-сессии.

Одним из решений такой проблемы является проверка внутри каждого экшна (хранится ли в сессии такой-то пользователь), но это неэкономно. Гораздо удобнее осуществлять подобную проверку до вызова экшна. Подобный подход в Struts 2 реализуется с помощью механизма перехватчиков, или интерцепторов (interceptors).

Очень часто мы используем на разных страницах сайтов повторяющийся код. Это может быть навигационное меню, рекламные блоки, стандартные формы поиска или входа на сайт. Такие фрагменты могут повторяться на множестве страниц, а иногда и на всех. Было бы нерационально на каждую страницу включать одинаковый код, который теоретически может измениться (например, в меню добавляется один пункт, следовательно, мы вынуждены корректировать код меню на каждой странице).
Любая серверная технология позволяет «собирать» страницы по фрагментам, чтобы не писать повторяющийся код много раз. То есть многократно используемый код выносится в отдельный файл, а затем в нужном месте включается в основной файл. Фреймворк Struts 2 предоставляет аналогичную возможность, которая реализована при помощи технологии Tiles («черепица»). Поясним на конкретном примере (см. иллюстрацию).

В первом занятии рассматривалась ручная валидация данных, которые были введены пользователем в форме, т.е если класс-экшин реализует интерфейс Validateable, то Struts вызывает метод validate.

Мы начинаем публикацию цикла учебных статей по Java-фреймворку Struts 2.