просмотр параметров - это то, что я использую, извините, я не понял, прочитал все ваши блоги, книги Burns / Geary, выпадают страницы. С непостоянными данными, такими как страница регистрации, у меня может быть 13 элементов данных, 13 X setPropertyActionListeners + f: viewParam. Но только попытайтесь передать ссылку на объект со страницы на страницу в том же веб-контейнере в том же jvm. С постоянными данными нужно передать первичный ключ, иметь конвертер, выполнить EntityManager.getReference () в методе getAsObject (). Должен быть лучший способ. Существует ли решение карты сеансов, которое может обрабатывать кластеризацию и несколько вкладок браузера?
я есть приложение, работающее на Mojarra 2.1.1 / Glassfish 3.1, которое теперь выросло до 150 000 строк кода. Приложение широко использует ajax с управляемыми компонентами ViewScoped и шаблоном page-redirect-get (то есть Face-Redirect = True).
Одна вещь, которая постоянно раздражает меня - это очевидное отсутствие простоты передачи параметров от страницы к странице и от bean к bean-компоненту (каждая страница имеет свой собственный bean-компонент).
Я не смог заставить работать вспышку. Обычно мне нужно получить доступ к данным, которые я записал во флэш-память, в прослушивателе событий preRenderView на следующей странице. Это не работает надежно, особенно после повторного развертывания приложения.
Я читал о CDI и провел несколько дней, пытаясь перейти от управляемых JSF-компонентов к bean-компонентам CDI, но не могу заставить его работать. Кажется, есть много проблем совместимости между Seam 3 и Glassfish 3.1. Я обновил Weld до 1.1.1, но это не помогает. С моей точки зрения это просто не работает в данный момент. Когда я говорю, что не работает, например, у меня есть страница, пытающаяся h: inputText в String в компоненте поддержки, и это не работает, очень простые вещи.
Из-за проблем с CDI у меня не получается использовать шовные лица @RenderScoped, которые в очень простом тестовом приложении (даже на g / f 3.1) делают то, что я хочу, но не в сложном основном приложении.
Единственный надежный механизм, который я могу найти для использования в настоящее время, это параметры URL, которые являются кошмаром безопасности. Несмотря на то, что делается все возможное, чтобы обеспечить правильную аутентификацию доступа к данным, всегда есть изменение, что-то пропущено, и вы видите ... xhtml? Id = 51031 или что-то еще в браузере - это слишком много для некоторых людей, чтобы сопротивляться попыткам других идентификаторов. Я написал конвертер обфускаций, чтобы избежать открытого текста и не использовать значимые имена для пар имя / значение, но это не приводит к корню проблемы.
Мне просто интересно, если я что-то здесь упустил, у всех ли есть рабочее решение этой проблемы, даже на стеклянной рыбе? Я слишком беспокоюсь и должен придерживаться URL-параметров? Любые другие предложения?
Благодарю.