JSF Conversations? Cid - правильный беспорядок, когда кто-то закладывает страницу - PullRequest
Новая
       28

JSF Conversations? Cid - правильный беспорядок, когда кто-то закладывает страницу

3 голосов
/ 19 октября 2011

Работа в JBoss AS7 с использованием Conversation Scope для управления взаимодействиями пользователя на вкладке браузера.

Замечу, что на мои страницы добавлены параметры? Cid. Это замечательно - пока пользователь не добавит страницу в закладки, а затем попытается вернуться на нее! Фильтр беседы выдает сообщение «Нет такой беседы».

Есть ли лучший способ управления разговорами? Возможно, реализация или переключение для использования скрытых полей (с соответствующей осторожностью в AJAX)? В качестве альтернативы мне придется начать пытаться перехватить исключение беседы или изменить фильтр!

Спасибо - Ричард

Далее:

Я перехватываю событие BeforeRestoreView для других целей (в основном для обработки входа в систему). Вы могли бы подумать, что это будет работать: 

/**
 * @return true if there is no valid Conversation context.
 */
private boolean conversationNotActive()
{
    Context conversationContext = m_beanManager.getContext(ConversationScoped.class);
    return !conversationContext.isActive();
}

Но я не могу получить контекст, чтобы спросить, активен ли он! Сейчас просто добавлю Try-Catch.

1 Ответ

2 голосов
/ 11 ноября 2011

Теперь мы используем двусторонний подход.

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

Для обычного GET Conversation Manager перенаправляет на себя без параметра cid, чтобы начать новый диалог. Для обратной передачи возвращается ошибка HTTP 410. Обнаружение мертвого разговора, как указано выше. Мы можем использовать более случайный идентификатор разговора, когда создаем диалоги, чтобы попытаться предотвратить столкновение, если идентификатор используется повторно.

Менеджер беседы также начнет разговор в зависимости от метаданных, которые он хранит о страницах. (Все страницы в / формы / требуют разговора в нашем приложении). При этом он использует перенаправление, чтобы гарантировать, что параметр CID находится везде, где он должен быть. Это может стать ненужным, если я смогу решить проблему получения идентификатора формы до фазы RestoreView.

Мы используем API истории браузера, чтобы удалить cid из окна URL браузера пользователя.

...