Sitecore:打开 HTML 缓存会阻止回发行为

发布于 2024-09-17 10:16:58 字数 314 浏览 2 评论 0原文

我有一个带有 ASP 下拉列表的 sitecore 页面,表单上的数据是从下拉列表中选定的值填充的。当下拉列表中的所选项目发生更改时,会触发回发。在回发中,新选定的项目将添加到查询字符串中,并且用户将被重定向(为了可链接性)。

我最近启用了 HTML 缓存(对于所有子布局,“根据查询字符串而变化”),但现在突然间,此机制不再起作用。似乎发生的是我选择一个新的下拉项,页面似乎回发(尽管如果我正在调试,我的断点都不会被击中)。之后,如果我再次更改所选项目,我可以在 Firebug 中看到消息“__doPostBack 未定义”,这似乎意味着 ASP 生成的 JavaScript 未添加到页面中。

I have a sitecore page with an ASP dropdownlist, and the data on the form is populated from the selected value of the dropdown. When the selected item of the dropdownlist is changed, a postback is fired. In the postback, the new selected item is added to the querystring and the user is redirected (for linkability).

I recently enabled HTML caching (for all sublayouts, "Vary by querystring"), and now suddenly, this mechanism no longer works. What seems to happen is I select a new dropdown item, the page appears to post back (though if I'm debugging, none of my breakpoints get hit). After that, if I change the selected item again, I can see in Firebug the message "__doPostBack is not defined", which appears to mean the ASP-generated JavaScript is not being added to the page.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

记忆消瘦 2024-09-24 10:16:58

为子布局启用缓存意味着您完全绕过代码,而 Sitecore 只是提供之前生成的相同 HTML。所以它的行为符合设计。换句话说,这似乎不是一个可以利用子布局缓存的场景。

Enabling caching for a sublayout means you are bypassing the code entirely and Sitecore is just serving up the same HTML it generated previously. So it's behaving as designed. In other words, this does not seem to be a scenario where you can take advantage of sublayout caching.

隔纱相望 2024-09-24 10:16:58

正如之前发布的,这正是预期的行为,因为页面是从缓存中获取的。您仍然可以支持非回发加载的缓存,但我发现的最简单的方法是使用 Global.asax 中的代码感知回发并进行相应的切换,如下面的示例所示。



    public override string GetVaryByCustomString(HttpContext context, string custom)
    {
        if (context.Request.RequestType.Equals("POST"))
        {
            context.Response.Cache.SetNoServerCaching();
            return "POST " + DateTime.Now.Ticks + " " + context.Request.RawUrl;
        }

        switch (custom)
        {
            case "RAWURL":
                return context.Request.RawUrl;
            default:
                return "";
        }
    }

然后,您可以将其挂钩到控件中的输出缓存指令:

<%@outputcache period="3600" Varbyparam="none" Varbycustom="RAWURL" %>

请注意,如果您这样做这样,您就失去了根据控件的数据源进行更改的简单能力。

As posted previously, this is expected behavior precisely because the page is being fetched from the cache. You can still support caching for non-postback loads, but the easiest way I've found is to sense the postback with code in Global.asax and switch accordingly, as in the sample below.



    public override string GetVaryByCustomString(HttpContext context, string custom)
    {
        if (context.Request.RequestType.Equals("POST"))
        {
            context.Response.Cache.SetNoServerCaching();
            return "POST " + DateTime.Now.Ticks + " " + context.Request.RawUrl;
        }

        switch (custom)
        {
            case "RAWURL":
                return context.Request.RawUrl;
            default:
                return "";
        }
    }

Then you can hook this to output cache directives in your controls:

<%@outputcache duration="3600" varybyparam="none" varybycustom="RAWURL" %>

Note that if you do it this way, you lose the easy ability to vary by a control's data source.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文