RenderStrategy.ONE_PASS_RENDER是一个合理的方法来摆脱页面版本参数,如Wicket应用程序中的？1？

Question

我们几年来一直在使用Wicket 1.3.7,目前正在将我们的项目升级到wicket 6.x

我做了很多关于页面版本参数(例如?1)附加到每个URL的研究,以及如何去掉它们.(遗憾的是,无法在官方文档中找到有关此内容的详细信息.)在这样做的同时,我阅读了很多语句(来自Wicket开发人员和用户,如

需要跟踪页面版本,否则不可能是有状态的

和

你需要让你的页面无状态才能摆脱它

还建议使用自定义实现AbstractComponentMapper,覆盖encodePageComponentInfo不附加参数.这有明显的缺点,即打破已安装页面的状态.(例如,参见这个SO答案)

昨天我偶然发现了RenderStrategy.ONE_PASS_RENDER.

我试了一下,经过一些测试,我得到的印象是这是"恢复旧的wicket方式"的设置:页面版本参数消失了,但我的页面是有状态的.

好的,也有一个缺点.如果必须自己处理双重提交问题,但我可以忍受.

问题:我还没有(还)知道其他任何缺点吗？有什么惊喜可以预料？

它似乎是一个完美的解决方案,我只是想知道为什么有这么多讨论如何摆脱这些参数,即使与wicket开发人员,这是不建议....

提前致谢.

Answer 1

我们经历了类似的升级路径,升级后我的第一反应是"哇,这些是一些讨厌的URL ......".

最初,我们还切换到一次通过渲染以获得更好的URL.但是在仔细研究之后,似乎"？id"不仅仅解决了双重求和问题.

具有Ajax组件的页面可能非常有状态:当用户与页面交互时,您添加组件,删除其他组件等.使用URL参数中的页面ID,您将返回与您离开时相同的状态页面刷新页面(F5)或导航到另一页,然后按后退按钮.

如果切换到一次传递渲染,则会丢失该功能,因为浏览器无法识别页面存储中的哪个页面是目标,并且通常最终会得到另一个页面对象实例.

这在"列表结果"页面(显示带有Ajax分页和过滤的"项目"列表/表的页面)中尤为明显.在具有一次渲染渲染的此类页面上,即使您多次单击"下一页",您也常常会丢失搜索条件或返回到结果的开头.

我们最终使用了"标准"渲染机制(不是一次通过渲染).网址看起来不太好,但我们觉得优点超过缺点(而且href确实看起来不错,它只是浏览器网址栏).

另一个问题是我们网站的"可抓取性".为了避免影响Google索引的302s或"url？id",我们在Wicket应用程序初始化方法中添加了以下代码,以强制Google Bot的一次渲染:

    setPageRendererProvider(new IPageRendererProvider() {
        @Override
        public PageRenderer get(RenderPageRequestHandler handler) {
            return new WebPageRenderer(handler) {
                @Override
                protected boolean isOnePassRender() {
                    // To avoid 302s with Google Bot and have good SEO.
                    String userAgent = ((HttpServletRequest) RequestCycle.get().getRequest().getContainerRequest()).getHeader("User-Agent");
                    if (StringUtils.contains(userAgent, "Googlebot")) {
                        return true;
                    } else {
                        return super.isOnePassRender();
                    }
                }
            };
        }
    });