1

最近，我重写了 Wicket 的DefaultPageStore方法serializePage和deserializePage并通过日志记录来增强它们以跟踪在它们中花费的时间。

我发现从未调用deserializePage，因为始终从SessionEntry#sessionCache检索实际页面。

我怀疑这是由于我的页面设置setVersionPagesByDefault(false)造成的情况，即只有当前版本的页面在SessionEntry中序列化，然后（不必要地）在DefaultPageStore中从不反序列化。

如果这个怀疑是正确的，那么我可以将方法serializePage设置为无操作 a 并跳过序列化，目前页面 X 需要 3 或 7 秒 (DeflatedJavaSerializer)。

到目前为止，我没有发现任何副作用，所以我的问题是：这安全吗？如果不是，那为什么？

我认为这只是临时解决方案，直到我能够将数据从页面移动到适当的缓存。

4

1 回答 1

1

以下是有关页面版本控制的一些信息：http ://wicket.apache.org/guide/guide/versioningCaching.html

如果您不需要对后退按钮的支持，您可以禁用页面版本控制 - 它没有副作用，假设您的页面正确处理后退按钮。跳回到没有状态的页面可以创建没有初始参数的页面。例如：您从页面 A 跳转到 B 并向 B 提供一些参数。现在用户在页面 C 上并单击返回按钮。这将导致重定向到页面 B，但这次不会传递任何参数。如果您使用页面版本控制，wicket 只会反序列化页面 B 并再次执行渲染。

这也是禁用页面存储的一种可能性：http: //maciej-miklas.blogspot.de/2013/09/wicket-6-disable-page-serialization.html

于 2014-05-13T21:44:22.577 回答