如何在数据加载时创建页面叠加 - asp.net/jquery/blockui

发布于 2024-12-12 03:59:02 字数 291 浏览 3 评论 0原文

当从 sql 服务器检索数据时，我试图显示一个叠加层，上面写着“页面加载...请稍候”。我希望为此使用 BlockUI 插件，但任何方法都可以。我有一个使用 site.master 的 ASP.NET 页面。该插件可以工作，但无论我尝试什么，它只会在页面完全加载后才会出现。

大部分等待时间都取决于 Global.asax 文件中完成的工作。在 Session_Start 部分中，我有一个函数返回数据以填充页面上的下拉菜单。这大约需要 20 秒才能完成。

那么，我需要做什么才能在页面完全加载之前查看叠加层？感谢您的任何帮助或建议。

原文

分享到QQ

分享到微博

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

发布评论

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

怪我入戏太深 2024-12-19 03:59:02

对于加载页面，插件不会起作用

如果您希望页面在加载之前被阻止，内容拦截器元素应该是页面的一部分，并且不是由始终在您的页面之后运行的任何插件生成的页面已加载。在某个时间点或另一个时间点。

<body>
   ...
   <!-- make it last -->
   <div id="blocker">
       <div>Loading...</div>
   </div>
</body>

让 CSS 完成剩下的工作

#blocker
{
    position: fixed;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    opacity: .5;
    background-color: #000;
    z-index: 1000;
}
    #blocker div
    {
        position: absolute;
        top: 50%;
        left: 50%;
        width: 5em;
        height: 2em;
        margin: -1em 0 0 -2.5em;
        color: #fff;
        font-weight: bold;
    }

，用 Javascript 清除阻塞：

$(function(){
    $("#blocker").hide();
});

这是使用上面代码的工作示例。它会在超时时删除阻止程序，因为它是一个非常简单的文档。

重要通知

但也许您没有以正确的方式理解这一点。也许您想在现有页面回发到服务器时阻止现有页面，因为这是一个不同的故事。在这种情况下，您的插件应该足够了，并且应该在 unload 窗口事件和显示阻止程序元素上运行。这会在现有页面回发数据时以及浏览器开始接收新内容之前阻止现有页面（可以使用之前显示的技术来阻止）。

看来问题是浏览器等待服务器响应

这很难说，因为你自己无法确定它。但假设问题是浏览器正在等待服务器响应。正如您提到的，会话加载速度很慢。有两件事：

优化数据库调用以更快地获取这些菜单数据（如果真的需要那么长时间 - 您是否使用分析器检查过？）
拥有一个静态默认 HTML 页面，用于显示正在加载内容并执行重定向：
- 使用 META 刷新标记 - 对于旧浏览器和没有 JavaScript 的浏览器来说更安全
- javascript - 更适合现代页面，特别是因为您的页面使用 Javascript（__doPostback 任何人）

看来您最好的选择是两者的结合。但一步一步走，看看是否会更好。

还有一件事。我知道等待第一个响应（应用程序启动）需要一些时间。很多页面都是这样做的。但人们通常不会真正打扰，因为用户无法对数据造成任何伤害，因为它仍然没有显示。当使用页面时响应时间很长时，情况会更糟，因为用户往往会多次单击同一按钮（例如在创建/更新数据时）。那危害更大。

也许您将 Asp.net 应用程序启动与会话加载混淆了。当您的应用程序首次启动时，服务器需要更长的时间来响应，因为它必须编译您的应用程序并启动它。这可能需要相当长的时间。有几种解决方法，包括更改应用程序回收时间和单独的心跳服务，这些服务向应用程序发出微小的请求，只是为了使其在较长时间不活动期间保持活动状态。

您还应该考虑到您的开发页面正在桌面计算机上运行。您应该知道您的服务器是否更快。

所以也许不是会话创建而是应用程序启动。您应该通过在浏览器中打开页面并等待其完成，然后关闭浏览器并再次打开它（以便创建新会话）并访问您的应用程序来区分差异。如果加载速度更快，那么这不是您的会话的错误，而是 .net 框架必须编译您的应用程序时应用程序启动的错误。

首先定义问题，然后开始缓解。

For loading pages, plugins won't do the trick

If you want your page to be blocked until it's loaded, content blocker element should be part of your page and not generated by any plugin that always run after your page has loaded. At some point in time or another.

<body>
   ...
   <!-- make it last -->
   <div id="blocker">
       <div>Loading...</div>
   </div>
</body>

And have CSS do the rest

#blocker
{
    position: fixed;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    opacity: .5;
    background-color: #000;
    z-index: 1000;
}
    #blocker div
    {
        position: absolute;
        top: 50%;
        left: 50%;
        width: 5em;
        height: 2em;
        margin: -1em 0 0 -2.5em;
        color: #fff;
        font-weight: bold;
    }

And Javascript that clears blocking:

$(function(){
    $("#blocker").hide();
});

This is a working example using the code above. It removes blocker on timeout, because it's such a simple document.

Important notice

But maybe you're not understanding this the right way. Maybe you would like to block existing page when it posts back to server, because that's a different story. In this case your plugins should suffice and should run on unload window event and display blocker element. This would block existing page while it posts back its data and before browser starts receiving new content (which can be blocked with previously shown technique).

It seems the problem is browser waiting for server response

It's hard to tell since you can't pin point it yourself. But suppose the problem is that browser is waiting for server to respond. And as you mention session loading is slow. Two things:

Optimise DB call to get those menu data quicker (if it really takes that long - have you checked with profiler?)
Have a static default HTML page that displays the Loading content and executes a redirect:
- using a META refresh tag - safer for old browsers and those without javascript
- javascript - better for modern pages and especially because your page is using Javascript (__doPostback anyone)

It seems that your best bet is the combination of both. But go one step at a time and see if it's better.

One more thing. I know that waiting for the first response (application start) takes some time. It does so on many pages. But people usually don't really bother since users can't do no harm with data because it's still not displayed. It's much worse when your response times are long when using the page, because users tend to click the same button several times (when creating/updating data for instance). That is much more harmful.

And maybe you're confusing the Asp.net application start-up with your session loading. When you application first starts it takes much longer for server to respond, because it has to compile your application and start it up. This can take considerable time. There are several workarounds for that that include changes to application recycling times and separate heartbeat services that make tiny requests to application just to keep it alive during longer time of inactivity.

You should also take into account that your in development page is running on a desktop machine. You should know whether your server is faster.

So maybe it's not the session creation but rather application start-up. You should tell the difference by opening a page in a browser and waiting for it to complete, then close the browser and opening it again (so new session will get created) and access your application. If it loads faster then it's not your session's fault but rather application start-up when .net framework has to compile your application.

Define the problem first then start mitigation.

回复收藏 0 原文