 |
|
|
|
Меньше кода, больше дохода. Часть 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. |
МИХАИЛ УШАКОВ, разработчик электронной аппаратуры и программного обеспечения для ядерной гаммарезонансной спектроскопии, Уральский федеральный университет, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
