Установка правил навигации в returnListener из диалога не работает в ADF 10g (JSF face 1.1) - PullRequest
0 голосов
/ 04 ноября 2011

У меня есть диалоговое окно подтверждения, созданное с использованием диалоговой структуры.Диалог открывается по командной ссылке, и значение, выбранное в tg, возвращается в прослушиватель возврата.Это моя командная ссылка.

              <af:commandLink id="btnSalva" shortDesc="Salva" 
                              binding="#{segnaPrzzDep.btnSalva}"
                              partialSubmit="true" immediate="true"
                              windowHeight="250"
                              windowWidth="350"
                              useWindow="true"
                              action="#{segnaPrzzDep.aclSalvaSegnaPrezzoDep}"
                              returnListener="#{segnaPrzzDep.rtlSalvaSegnaPrezzoDep}"
                              styleClass="btnSalva"/>

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

    FacesContext fc = FacesContext.getCurrentInstance();
    NavigationHandler nh =  fc.getApplication().getNavigationHandler();
    nh.handleNavigation(fc, "", "archivio");

Самое удивительное, что если я использую диалоговую среду, но без открытия окна, все в порядке.Я установил командную ссылку так:

              <af:commandLink id="btnSalva" shortDesc="Salva" 
                              binding="#{segnaPrzzDep.btnSalva}"
                              partialSubmit="true" immediate="true"
                              action="#{segnaPrzzDep.aclSalvaSegnaPrezzoDep}"
                              returnListener="#{segnaPrzzDep.rtlSalvaSegnaPrezzoDep}"
                              styleClass="btnSalva"/>

Все работает правильно.Я использую jDev 10.3.1.4 и ту же версию ADF.

Ответы [ 2 ]

3 голосов
/ 23 ноября 2011

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

Я полагаю, что основная причина будет одинаковой в обоих наших случаях, даже если я использую библиотеку Тринидад, а не ADF. Lib Trinidad на самом деле был ответвлением от ADF, поэтому они делят довольно много кода.

В моем случае мы перешли с Тринидада 1.0.7 на Тринидад 1.0.10 (из-за этой проблемы).

Из-за этого обновите тег "commandButton" в наших jsp-файлах, определенных как

<tr:commandButton ... returnListener="bean.listenerMethod" ... useWindow="true" />

перестает вызывать bean.listenerMethod, когда закрывается диалог, в котором присутствует эта кнопка. Установка useWindow = "false" вызывает повторный вызов bean.listenerMethod.

Перед обновлением упомянутая команда commandButton хорошо работала в обоих случаях (useWindow = "true" / "false").

Итак, как вы видите, симптомы очень похожи.

Теперь о выводах, которые я сделал при анализе этой проблемы.

Проверяя журналы, я заметил, что класс LifeCycleImpl не вызывает все фазы при возврате на главную страницу (после закрытия диалога).

Итак, 1) сообщение в диалоге было обработано, что означает, что все этапы были обработаны, и 2) впоследствии была вызвана главная страница, но на этот раз самая первая фаза «представление восстановления» была только что обработана, а затем перешла непосредственно к « фаза отображения ответа, вызывающая главную страницу без вызова bean.listenerMethod.

При проверке одних и тех же журналов на Тринидаде 1.0.7 все фазы, которые также вызывались на шаге 2).

Я отладил источники Тринидада 1.0.10 и отследил эту разницу, вызванную этой"ошибкой".

Проблема в том, что UIViewRoot удаляется из сессии. При последующем вызове закрытия в диалоговом окне фаза «восстановление представления» во время (описанного выше) шага 2) не может найти UIVIewRoot главной страницы.

Когда это происходит, LifeCycleImpl решает пропустить напрямую к «фазе рендеринга», так как, вероятно, ожидает, что из-за отсутствия UIViewRoot в сеансе это первый вызов страницы (представление), и поэтому он просто перезагружает главную страницу .

Я новичок в JSF, но для меня это выглядит как ошибка.

В моем случае на меня оказывается большое давление, чтобы как-то решить эту проблему, поэтому давайте посмотрим, что я смогу с этим сделать.

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

Я отправил новую ошибку в https://issues.apache.org/jira/browse/TRINIDAD-2171.

Я нашел решение этой проблемы.В моем проекте я создал класс и пакет как org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java.

. В этот класс я скопировал все из соответствующего класса в lib Тринидада.Затем я прокомментировал изменения, внесенные из-за исправления в https://issues.apache.org/jira/browse/TRINIDAD-1193.

Наконец, я убедился, что мой класс загружается первым, а не из тринидада lib (в tomcat это было сделано путем копирования класса в WEB_INF \ classesdir, поскольку этот dir вызывается первым при загрузке классов, т. е. перед загрузкой WEB-INF \ libs, в который помещается библиотека Тринидада).

...