JSF Conversations ?cid - 当有人为页面添加书签时会出现混乱吗？
在 JBoss AS7 中工作，使用对话范围来管理用户在浏览器选项卡中的交互。
我注意到我的页面附加了 ?cid 参数。这太棒了 - 直到用户为该页面添加书签然后尝试返回该页面！对话过滤器给出“没有这样的对话”消息。
有没有更好的方式来管理对话？也许是一个实现或一个开关以使其使用隐藏字段（在 AJAX 中适当注意）？或者，我必须开始尝试拦截对话异常或修改过滤器！
谢谢 - Richard
进一步：
我正在拦截 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 进去。
Working in JBoss AS7, using Conversation Scope to manage the user's interactions within a browser tab.
I note that my pages get ?cid parameters appended. This is great - until the user bookmarks the page then tries to return to it! The Conversation Filter gives a "No such conversation" message.
Is there a better way of managing conversations? Perhaps an implementation or a switch to make it use hidden fields (with appropriate care in AJAX)? Alternatively I'll have to start trying to intercept the Conversation Exception or modify the filter!
Thanks
- Richard
Further:
I'm intercepting the BeforeRestoreView event for other purpose (login handling mainly). You'd think this would work:
/**
* @return true if there is no valid Conversation context.
*/
private boolean conversationNotActive()
{
Context conversationContext = m_beanManager.getContext(ConversationScoped.class);
return !conversationContext.isActive();
}
But I can't get the context to ask if if it's active! Will just throw a Try-Catch in for now.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们现在采取两管齐下的方法。
相当复杂的对话管理器会检测到错误的对话 ID 并采取适当的操作。它当前响应“恢复后视图”事件。我想提前移动它，但现阶段在导出视图 ID 时遇到问题。我编写了一个 JSF 到 CDI 的桥来将事件传递到 CDI。 SeamFaces 也会做同样的事情，但事实证明对我们来说太重量级了。
对于正常的 GET，会话管理器会重定向到 self（不带 cid 参数），以便启动新的会话。对于回发，它会返回 HTTP 410 错误。死会话的检测如上。当我们创建对话时，我们可以使用更随机的对话 ID，以防止重用 ID 时发生冲突。
对话管理器还将根据其保存的有关页面的元数据开始对话。 （/forms/ 下的所有页面都需要在我们的应用程序中进行对话）。执行此操作时，它会使用重定向来确保 CID 参数位于所需的任何位置。如果我能在 RestoreView 阶段之前解决获取表单 ID 的问题，这可能就变得不必要了。
我们使用浏览器历史记录 API 从用户的浏览器 URL 窗口中删除 cid。
We now take a two pronged approach.
A quite complex conversation manager detects a bad conversation Id and takes appropriate action. It responds currently to the After Restore View event. I'd like to move it earlier but am having problems deriving the view ID at this stage. I've written a JSF to CDI bridge to pass the events to CDI. SeamFaces would do the same, but proved too heavyweight for us.
For a normal GET the Conversation Manager redirects to self without the cid parameter in order to cause a new conversation to be started. For a postback it returns an HTTP 410 error. The detection of dead conversation is as above. We could use a more random conversation Id when we create conversations to try to prevent collision if an ID is reused.
The Conversation Manager will also start a conversation depending on metadata it holds about the pages. (All pages under /forms/ require a conversation in our application). It uses redirect when it does this to ensure that the CID parameter is everywhere it needs to be. This may become unnecessary if I can solve the problem of getting the form ID before RestoreView phase.
We use the browser history API to remove the cid from the user's browser URL window.