5

我在组织内推广 JQuery 方面相当成功。靠它自己可不是小事。然而，为了使它成为我们应用程序的一部分，这里提出的一个想法是创建一个 ASP.net 服务器端控件。（在可预见的未来，我们将坚持使用 WebForms。）

我对这种方法并不太狂热，因为当几个脚本标签可以完成这项工作时，这似乎有点过头了。我们在网上找到了一篇文章，涉及的代码量似乎并不能证明其合理性。但是，我确实听说在脚本缓存或生成服务器控件时会产生一些好处。

我的问题：

  • 有没有其他人编写过 ASP.net 服务器控件来提供 JQuery js 代码？
  • 有没有其他人认为避免编写 JQuery 或 Javascript 代码是一个疯狂的想法？
4

4 回答 4

4

我知道微软（连同诺基亚）正在“主流化” jQuery，并将把它与 Visual Studio 的未来版本集成。您可能想探索他们将如何正式使用它，以便您现在可以定制您的设置，并希望在以后轻松过渡到“官方 MS jQuery”。

于 2008-10-06T15:14:03.053 回答
2

我同意你的看法。不值得花时间创建和创建控件以添加 JQuery 脚本位置。

更好的解决方案是拥有 1 个 .js 文件，其中包含在页面上加载所需的所有链接。如果这是团队的问题，那可以消除分配的 .js 链接。

唯一一次我会原谅创建自定义控件以仅链接 JavaScript 是出于某种原因，您不想将 JavaScript 复制到服务器并希望将其嵌入到 .dll 中。但是，您不会阻止人们在页面上看到 JavaScript，因为如果您将文件嵌入到 .dll 中，您必须在标头中将它们注册为完整的脚本文件。

于 2008-10-06T15:17:51.687 回答
1

使用服务器控件注入 JavaScript 引用的一个原因是更容易控制将哪些 JavaScript 文件添加到页面。想象一个场景，你使用 jQuery 核心，加上 jQuery UI 和一些其他插件。根据您对该控件的编码方式，您可以让开发人员轻松选择特定页面所需的功能，而无需担心所需的特定脚本。这种方法可以为您的应用程序分段提供很大的灵活性：例如，服务器控件可能被母版页、子页、用户控件或其他服务器控件使用。如果母版页注册了对一个 jQuery 库的要求，但子页或用户控件之一需要其他库，那么拥有统一的 API 会使这变得简单。亲自，

底线是您希望每个开发人员重新发明轮子或使用通用、易于使用的 API 来强制您的应用程序的一致性。

于 2008-10-06T23:35:29.343 回答
0

我找到了 Scott Hanselman 的博客文章，其中包含一个具有 ASP.net AJAX + JQuery 的示例应用程序。这是一个简单的应用程序，但它包含所有带有脚本标签的 javascript。我没有看到任何建议使用服务器控件来提供脚本。

于 2008-10-06T15:35:41.260 回答