在对话框的 returnListener 中设置导航规则在 ADF 10g 中不起作用(JSF faces 1.1)
我有一个使用对话框框架创建的确认对话框。该对话框通过命令链接打开,并且在 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。
I've a confirmation dialog created using the dialog framework. The dialog is opened by a command link and the value selected in tg is returned to a return listener. This is my command link.
<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"/>
In the return listener i try to set a navigation rule, but nothing happens. I do it like this (the return handler does only this):
FacesContext fc = FacesContext.getCurrentInstance();
NavigationHandler nh = fc.getApplication().getNavigationHandler();
nh.handleNavigation(fc, "", "archivio");
The starnge thing is that if i use the dialog framework but withouth opening the window everything is ok. I f i set-up the command link like this:
<af:commandLink id="btnSalva" shortDesc="Salva"
binding="#{segnaPrzzDep.btnSalva}"
partialSubmit="true" immediate="true"
action="#{segnaPrzzDep.aclSalvaSegnaPrezzoDep}"
returnListener="#{segnaPrzzDep.rtlSalvaSegnaPrezzoDep}"
styleClass="btnSalva"/>
Everything works correctly. I'm using jDev 10.3.1.4 and the same version of ADF.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我刚刚写了一个非常相似的问题,然后我注意到你已经发布了它。
我猜想,即使我使用的是 trinidad lib 而不是 ADF,我们这两种情况的根本原因也是相同的。 trinidad 库实际上是 ADF 的一个分支,因此它们共享相当多的代码。
就我而言,我们已从 trinidad 1.0.7 迁移到 trinidad 1.0.10 (由于 this问题)。
由于此升级,我们的 jsp 文件中定义的“commandButton”标记
在关闭此按钮所在的对话框时停止调用 bean.listenerMethod。
设置 useWindow="false" 会导致再次调用 bean.listenerMethod。
升级之前,上述命令按钮在两种情况下都运行良好(useWindow="true"/"false")。
正如您所看到的,症状非常相似。
现在来说说我在分析这个问题时得出的结论。
通过检查日志,我发现 LifeCycleImpl 类在返回主页(关闭对话框后)时并未调用所有阶段。
因此,1)处理了对话框上的帖子,这意味着所有阶段都已处理,2)之后调用了主页,但这一次刚刚处理了第一个阶段“恢复视图”,然后直接跳转到“渲染响应”阶段调用主页面而不调用 bean.listenerMethod。
在 trinidad 1.0.7 上检查相同日志时,所有阶段也在步骤 2) 中调用。
我已经调试了 trinindad 1.0.10 的源代码,并跟踪了由 this“错误”。
这里的问题是 UIViewRoot 正在从会话中删除。然后,当在对话框上调用 close 时,(如上所述)步骤 2)中的“恢复视图”阶段无法找到主页的 UIVIewRoot。
发生这种情况时,LifeCycleImpl 决定直接跳到“渲染阶段”,因为它可能认为由于会话中缺少 UIViewRoot,这是对页面(视图)的第一次调用,因此它只是重新加载主页。
我对 JSF 很陌生,但对我来说这看起来像是一个错误。
就我而言,我面临着以某种方式解决这个问题的巨大压力,所以让我们看看我能用这个做什么。
I have been just writing a very similar question, then i noticed that you have already post it.
I guess that the root cause will be the same in both our cases even that I am using the trinidad lib not ADF. The trinidad lib was actually a fork from ADF so they share quite a lot of code.
In my case, we have migrated from trinidad 1.0.7 to trinidad 1.0.10 (due to this problem).
Because of this upgrade the "commandButton" tag in our jsp files defined as
stops calling the bean.listenerMethod when the dialog where this button is present is closed.
Setting useWindow="false" causes the bean.listenerMethod to be called again.
Before the upgrade, the mentioned commandButton worked well in both cases (useWindow="true"/"false").
So as you can see the symptoms are very similar.
Now for the findings that i have made when analysing this issue.
By checking the logs I observed that the LifeCycleImpl class did not invoke all of the phases when returning back to the main page (after closing the dialog).
So 1) the post on the dialog was processed, which means all phases were processed and 2) the main page was called afterwards, but this time the very first phase "restore view" was just processed and then jumped directly to "render response" phase calling the main page without invoking the bean.listenerMethod.
When checking the same logs on trinidad 1.0.7 all of the phases where called also in step 2).
I have debugged the sources of trinindad 1.0.10 and tracked this difference to be caused by this "bug".
The problem here is that the UIViewRoot is being removed from session. When then calling close on the dialog, the "restore view" phase during (described above) step 2) can not find the UIVIewRoot of the main page.
When this happen, LifeCycleImpl decides to skipp directly to the "render phase" since it is probably expecting that due to missing UIViewRoot in the session this is the first call to the page (view) and so it just reloads the main page.
I am quite new to JSF but to me this looks like a bug.
In my case there is quite a high pressure on me to fix this problem somehow, so lets see what i will be able to do with this.
我已将一个新错误发布到 https://issues.apache.org/jira/browse/ TRINIDAD-2171。
我已经找到解决这个问题的方法。在我的项目中我创建了一个类和一个包
如
org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
。对于这个类,我已经复制了 trinidad lib 中相应类的所有内容。然后我
已注释掉由于 https://issues.apache.org/jira/ 中的修复而完成的更改浏览/TRINIDAD-1193。
最后,我确保我的类在 trinidad lib 中的类之前首先加载(在 tomcat 中,这是通过将类复制到 WEB_INF\classes 目录来完成的,因为在加载类时,即在加载 WEB-INF 之前,该目录被称为第一个目录) \libs 放置 trinidad lib 的位置)。
I have posted a new bug to https://issues.apache.org/jira/browse/TRINIDAD-2171.
I have find a workaround for this problem. In my project I created a class and a package
as
org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java
.To this class i have copied everything from corresponding class in trinidad lib. Then i
have commented out changes done due to fix in https://issues.apache.org/jira/browse/TRINIDAD-1193.
Finally I make sure that my class gets loaded first before the one from trinidad lib (in tomcat this was done by coping the class to WEB_INF\classes dir, since this dir is called as first one when loading classes, i.e. before loading WEB-INF\libs where trinidad lib are placed).