JSF / Mojarra проблемы "флеш прицел" - PullRequest
Новая
       38

JSF / Mojarra проблемы "флеш прицел"

3 голосов
/ 18 июня 2011

У меня есть приложение, работающее на Mojarra 2.1.1 / Glassfish 3.1, которое теперь выросло до 150 000+ строки кода. Приложение широко использует ajax с управляемыми компонентами ViewScoped и шаблон перенаправления страницы-get (т.е. Face-Redirect = True).

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

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

Я прочитал о CDI и провел несколько дней, пытаясь перейти от управляемых компонентов JSF к бобам CDI, но не могу заставить его работать. Кажется, есть много проблем с совместимостью между швом 3 и Glassfish 3.1. Я обновил Weld до 1.1.1, но это не помогает. От моя точка зрения это просто не работает в данный момент. Когда я говорю, что не работает, например У меня есть страница, пытающаяся h: inputText в строку в компоненте, и это не работа, действительно простые вещи.

Из-за проблем с CDI я не могу использовать швы @RenderScoped, которые в очень простое тестовое приложение (даже на g / f 3.1) делает то, что я хочу, но не в комплексное основное применение.

Единственный надежный механизм, который я могу найти для использования в настоящее время, это параметры URL, которые являются кошмар безопасности. Несмотря на то, что делается все возможное, чтобы обеспечить доступ к данным при правильной аутентификации всегда есть что-то пропустить и увидеть ... xhtml? id = 51031 или что-то в браузере слишком много, чтобы некоторые люди сопротивлялись пробуя другие идентификаторы. Я написал конвертер запутывания, чтобы избежать открытого текста и не используйте значимые имена для пар имя / значение, но это не доходит до корня проблема.

Мне просто интересно, что я что-то здесь упустил, у всех ли есть рабочее решение? к этой проблеме даже на стеклянных рыбках? Я слишком беспокоюсь и должен придерживаться URL Титулы? Любые другие предложения?

Спасибо.

Ответы [ 2 ]

3 голосов
/ 21 августа 2011

Я видел то же самое. В то время, когда я это пробовал, Seam3 был очень глючным, и его было очень трудно развернуть на разных серверах. Я перешел на MyFaces CODI , который с самого начала работал без проблем. В вашем случае вы должны взглянуть на @ViewAccessScoped. Вы можете избавиться от всех этих надоедливых обходных путей.

2 голосов
/ 18 июня 2011

Объявите параметры, которые вы хотели бы установить или передать в следующем представлении в 

<f:metadata>
    <f:viewParam name="foo" value="#{bean.foo}" />
</f:metadata>

В основном это bean.setFoo(request.getParameter("foo")) на этапе обновления значений модели запроса GET.

Если вы добавите параметр includeViewParams=true к результату навигации, то те, которые объявлены как <f:viewParam> текущего представления, будут переданы следующему представлению. 

public String doSomething() {
    // ...
    return "next?faces-redirect=true&amp;includeViewParams=true";
}

(примечание: &amp; важен! & не будет работать, так как не соответствует XML)

Следующее представление должно иметь тот же <f:viewParam>, чтобы их можно было установить в bean-компоненте. И так далее.

...