Меньше кода, больше дохода. Часть 3. Tapestry для создания Java EE-приложений

 МИХАИЛ УШАКОВ, разработчик электронной аппаратуры и программного обеспечения для ядерной гаммарезонансной спектроскопии, Уральский федеральный университет, um.nix.user@gmail.com

Меньше кода, больше дохода
Часть 3. Tapestry для создания Java EE-приложений

В прошлой части статьи [1] мы рассмотрели, как настроить Back-end слой, получить данные через менеджера данных и отображать их в простой CRUD-компонент в виде HTML-таблицы со ссылками для удаления, редактирования и добавления записей в базу данных. Как использовать базовые возможности Tapestry?

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

Понятие состояния и сохранение состояний

При каждой перезагрузке веб-страниц, созданных с использованием Apache Tapestry, происходит полная очистка полей классов, восстанавливаются значения по умолчанию (даже статические), если поля помечены аннотациями для IoC (@Inject, @InjectComponent, @InjectPage), например, в предыдущей статье мы инициализировали менеджер данных:

@Inject

private IDatabaseManager databaseManager;

Рассмотрим ситуацию, когда мы редактируем информацию о пользователе (профиль пользователя) и нажимаем клавишу <F5> или перезагрузку страницы в браузере, все поля ввода, как отредактированные, так и инициализированные строкой, заменяются из таблицы базы данных. Подобное поведение не будет дружелюбным по отношению к конечному пользователю. Одним из вариантов является использование Persist-полей. Persist-поле будет сохранять свое значение до тех пор, пока не будут закрыты все соединения с сервером. Чтобы использовать Persist-поля, необходимо взять аннотацию @Persist (никто и не думал, что аннотация будет носить другое имя):

@Persist

private User currentUser;

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

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

Статью целиком читайте в журнале «Системный администратор», №5 за 2014 г. на страницах 56-60.

Комментарии могут оставлять только зарегистрированные пользователи