关于Wicket页面id机制的见解

在过去的几周里，我已经阅读了很多文档和代码，但是对于一些特殊的问题，我仍然无法“连接点”了解页面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能够处理所有事情

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

打开左边的页面

操纵左侧页面

打开右边的页面

操纵正确的页面

操纵左侧页面

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

---

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

这里有一个指向Wicket指南相关部分的链接：

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

---

如果无法实现页面序列化，可以使用所述的

HttpSessionDataStore

，将页面保留在http会话中。如果你要走这条路线，也可以从邮件列表中查看一下，因为它包含要避免的重要陷阱。

你看到了吗？如果没有，先读它，它可以连接一些点。事实上，这连接了一些点。显然，反序列化发生是因为左侧页面不再位于会话缓存中。是否有可能对此进行调整？我的主要问题是，反序列化会导致整个页面的重新加载，这会导致一些可用性问题。什么样的可用性问题？是不是太慢了？如果是这样，这可能是由于您的页面和组件未使用可分离模型或未正确分离它们造成的。这可能会导致页面变得非常大，具体取决于您在模型中存储的内容。Javascript组件会重新加载并失去其状态（选择等）。我宁愿停止重新加载，也不要担心现在和将来的每个组件都必须将其状态永久地发送回服务器，并在重新加载后再次检索。这是一个巨大的开销。此外，一些组件需要相当长的时间来渲染（不可更改）。在您的特定情况下，您可以使用

HttpSessionDataStore

。请参阅：我这边的一点补充：如果您想完全禁用序列化，而不仅仅是阻止磁盘上的存储，还不足以使用

HttpSessionDataStore

，那么还需要做一些额外的工作，比如在回答Jesse Barnum的另一个问题时：