关于Wicket页面id机制的见解

Question

在过去的几周里，我已经阅读了很多文档和代码，但是对于一些特殊的问题，我仍然无法“关联”页面ID机制的工作原理。让我描述一下情况。

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

我的理解如下：

• Wicket的页面ID是会话唯一的。这样，例如首先显示的左页是id？0，右页是id？1。
  • 理论： Wicket仅支持一个“当前”页面ID，这是会话中使用的最高ID。这样，即使我还没有操作页面，左页的id？0在技术上已经过时了，刷新它会产生id？2。这是正确的假设吗？
• 以影响Wicket后端的方式操作页面会增加此ID - 同样，会话唯一。如果我第一次操纵正确的页面，它会获得id？2。如果我现在操纵左页，它会得到id？3 - 在实践中它有时甚至会得到id？4，不完全确定是什么导致这个，但那不是问题。
• Wicket的重新渲染算法包括页面的序列化和反序列化。
  • 理论：如果刷新一个带有“过时”ID的页面（参见上面的理论），反序列化是要走的路（至少那是我的调试尝试告诉我的，但那个深在Wicket代码中，不容易看到最新情况和原因。这是一个正确的假设 - 我可以通过反序列化在id 0下保存在页面存储中的内容来从id？0转到id？3吗？

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

只要我只使用一个窗口，一切都很好。这个页面的页面ID有时会增加，但是wicket能够处理所有内容。

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

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

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

我现在的问题如下：我对页面ID机制的工作方式的假设是否正确？这种反序列化是必要的还是可以避免的？是否仅因为一些配置错误而发生（如果您有特定问题，我可以提供更多配置详细信息）？为什么会这样呢？就像我说的那样，我试着深入研究这段代码，但我希望能够对那些更熟悉它的人做一些澄清。

Answer 1

以下是Wicket指南相关部分的链接：

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

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

如果您无法负担序列化页面的费用，则可以使用HttpSessionDataStore描述的here来保持http会话中的页面。如果您要走这条路线，请查看邮件列表中的this email thread，因为它包含要避免的重要问题。