关于Wicket页面id机制的见解

Question

在过去的几周里，我读了很多留档和代码，但是对于一些特殊的问题，我仍然无法“连接”页面标识机制是如何工作的。让我概述一下情况。

在我的Wicket应用程序中，有两个页面在同一个会话中并行运行（两个监视器设置，我将它们称为“左”和“右”页面）。

我所理解的是以下几点：

• Wicket的页面ID是会话唯一的。这样，例如，首先显示的左侧页面会获取id？0，正确的页面获取id？1.

• 理论：如果要用“过时”的id刷新页面（参见上面的理论），反序列化是一种方法（至少我的调试尝试告诉我了这一点，但在Wicket代码的深处，不太容易看到发生了什么以及为什么）。这是正确的假设吗？我只能从id开始吗？0到id？3通过反序列化id为0的页面存储中保存的内容

现在是棘手的部分——我们的Wicket应用程序嵌入到OSGi环境中，页面上显示的组件实际上是在不同的捆绑包中实现的。因此，无论何时发生上述反序列化，结果都是一个很好的反序列化异常，因为Wicket无法再访问组件的类。使用wicketstuff osgi和依赖注入解决了这个问题。

只要我只使用一个窗口，一切都很好。这个页面的页面标识偶尔会增加，但是wicket能够处理一切。

当有两个页面时，会发生以下情况：

1. 打开左边的页面。
2. 操纵左边的页面。
3. 打开正确的页面。
4. 操纵正确的页面。
5. 操纵左边的页面。

显然，现在wicket发现左页面的页面id必须“跳转”，在这个id跳转的过程中，id为0的旧页面需要反序列化。

我现在的问题如下：我对页面id机制如何工作的假设正确吗？这种反序列化是必要的还是可以避免的？这是否只是因为一些配置错误（如果您有具体问题，我可以提供进一步的配置细节）？为什么会这样？正如我所说，我试图深入研究该代码，但我希望更熟悉该代码的人能给出一些澄清。

Answer 1

以下是Wicket指南相关章节的链接：

http://wicket.apache.org/guide/guide/versioningCaching.html

它详细解释了页面版本控制和涉及的不同部分。

如果您负担不起对页面进行序列化，可以使用此处描述的HttpSessionDataStore，它将页面保留在http会话中。如果你要走这条路线，也可以看看邮件列表中的这条邮件，因为它包含了需要避免的重要问题。