在过去的几周里，我阅读了大量的文档和代码，但对于一些特殊问题，我仍然无法“了解”页面 ID 机制的工作原理。让我大致描述一下情况。
在我的 Wicket 应用程序中，有两个页面在同一 session 中并行运行(双显示器设置，我将它们称为“左”和“右”页面) .
我的理解是:
- Wicket 的页面 ID 是 session 唯一的。这样，例如首先显示的左侧页面获得 id ?0，右侧页面获得 id ?1。
- 理论: Wicket 仅支持一个“当前”页面 ID，即 session 中使用的最高 ID。这样，即使我还没有操作页面，左侧页面的 id ?0 在技术上已经过时，刷新它会产生 id ?2。这是一个正确的假设吗？
- 以影响 Wicket 后端的方式操作页面会增加此 ID - 同样， session 唯一。如果我首先操作正确的页面，它会得到 id ?2。如果我现在操作左侧页面，它会得到 id ?3 - 实际上有时它甚至会得到 id ?4，不完全确定是什么原因导致的，但这不是问题。
- Wicket 的重新呈现算法包括页面的序列化和反序列化。
- 理论:在使用“过时”id 刷新页面的情况下(参见上面的理论)，反序列化是可行的方法(至少那是我的调试尝试告诉我的，但是那么深在 Wicket 代码内部，要了解发生了什么以及为什么不是特别容易)。这是一个正确的假设吗？我只能通过反序列化 id 0 下保存在页面存储中的内容从 id ?0 移动到 id ?3 吗？
现在到了棘手的部分 - 我们的 Wicket 应用程序嵌入到 OSGi 环境中，页面上显示的组件实际上是在不同的包中实现的。因此，无论何时发生刚刚提到的反序列化，结果都是一个很好的反序列化异常，因为 Wicket 无法再访问组件的类。使用 wicketstuff-osgi 和依赖注入(inject)解决了这个问题。
只要我只使用一个窗口，一切都很好。此页面的页面 ID 有时会增加，但 wicket 能够处理所有事情。
当有两个页面时，会发生以下情况:
- 打开左侧页面。
- 操作左侧页面。
- 打开右侧页面。
- 操作正确的页面。
- 操作左侧页面。
显然，现在 wicket 发现左侧页面的页面 id 必须“跳转”，并且在这个 id 跳转的过程中，id 为 0 的旧页面需要反序列化。
我现在的问题如下:我对页面 ID 机制如何工作的假设是否正确？这种反序列化是必要的还是可以避免的？它是否只是因为某些错误配置而发生(如果您有具体问题，我可以提供更多配置细节)？为什么会这样？正如我所说，我尝试深入研究该代码，但我希望更熟悉它的人能提供一些说明。
最佳答案
这是 Wicket 指南相关部分的链接:
http://wicket.apache.org/guide/guide/versioningCaching.html
它详细解释了页面版本控制和涉及的不同部分。
如果您无法承受页面序列化，您可以使用 HttpSessionDataStore 描述 here它将页面保留在 http session 中。看看this email thread如果您要走那条路线，也可以从邮件列表中获取，因为它包含要避免的重要问题。
关于wicket - Wicket 页面 id 机制的见解，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22180351/