是否值得花时间从 AjaxControlToolkit 切换到 jQuery?

发布于 2024-09-01 06:28:28 字数 370 浏览 5 评论 0原文

我不断听到关于 jQuery 有多棒以及 AjaxControlToolkit 有多糟糕的事情。不幸的是,我只是在使用该工具包构建了整个 WebForms 站点之后才听说了这一点。

现在我正在考虑(如果不是完全的话)主要转向 jQuery。这部分是为了体验(从未用 Javascript 编码或使用过任何框架),部分是因为我认为我对 jQuery 有更多的控制权。

没有迫切需要切换,但无论如何我正在考虑这样做。

是否值得为了获得经验而解决 jQuery 的学习曲线,我是否应该让我的工作站点保持足够的状态?

I keep hearing all these things about how awesome jQuery is and how the AjaxControlToolkit sucks. Unfortunately, I only heard about this after I built my entire WebForms site using the toolkit.

Now I am considering switching, if not entirely, mostly to jQuery. This is partially for the experience (having never coded in Javascript or used any frameworks) and partially because I think I have more control over jQuery.

There is no pressing need to switch, but I'm considering doing it anyway.

Is it worth tackling the learning curve for jQuery just to get the experience, of should I leave my working site well enough alone?

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

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

发布评论

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

评论(3

翻身的咸鱼 2024-09-08 06:28:28

jQuery 无疑为您提供了更大的灵活性,但这实际上取决于您需要什么功能。

虽然 jQuery 使用起来很容易上瘾,但 jQueryUI 控件库却相当简约。尽管 jQuery 有许多很棒的插件,但它们的外观本质上是不一致的。相反,使用单一供应商的 UI 控件的好处是,您可以使所有内容的外观和行为保持一致,这也使网站显得更加专业。

我从未使用过 AjaxControlToolkit,但我相信您应该能够将 jQuery 包含到页面中。如今这些优秀的框架彼此都非常友好。这样您就可以两全其美。它还减少了“切换”期间必须完成的工作量,并提供了从一种到另一种的更渐进的过渡。

jQuery definitely gives your more flexibility, but it really depends on what functionality you need.

While jQuery is quite addictive to use, the jQueryUI control library is quite minimalistic. Though there are many awesome plugins for jQuery, the look-and-feel of those are inherently inconsistent. On contrary, the nice thing about using UI controls from a single vendor is that you get everything look and behave consistently which also makes the site appear more professional.

I never used AjaxControlToolkit, but I believe you should be able to include jQuery to the page. Nowadays these great frameworks are quite friendly to each other. That way you can get the best out of both worlds. It also reduces the amount of work you have to do during the "switch", and offers a more graduated transition from one to another.

要走干脆点 2024-09-08 06:28:28

我只会使用 jQuery 和 AjaxControlToolkit。我现在正在做这个。总而言之,他们彼此相处得很好。请注意,当 Toolkit 执行 AJAX 回发时,jQuery 并不知道,因此您必须链接文档加载和 onpostback 事件。

I would just use both jQuery and AjaxControlToolkit. I am doing this now. All in all, they play pretty nice with each other. Just be aware that when Toolkit does an AJAX postback, jQuery doesn't know it, so you have to chain both the document load and the onpostback events.

在风中等你 2024-09-08 06:28:28

根据最近的经验,我正在考虑从 AjaxControlToolkit 完全切换到 Jquery。这是由于一次事件造成的,我们尝试在旧应用程序的虚拟目录中托管新应用程序。

较旧的应用程序运行 System.Web.Extensions 版本 1.06,但较新的应用程序需要版本 3.5(对于 AjaxControlToolkit 3.5)。由于 IIS 的结构方式,它将继承父级的 web.config 文件,从而导致各种问题和错误,因为应用程序将找到两个版本的 system.web.extensions。这个问题没有解决,我们必须将 web 应用程序托管在一个新的子域下。

如果我们只使用 jQuery,这个问题是可以避免的,因为它与 IIS 完全解耦。

From recent experience, I am thinking of switching from AjaxControlToolkit to Jquery completely. This is due to an incident, where we tried to host a new application in a virtual directory of an older application.

The older application was running System.Web.Extensions version 1.06, but the newer application needed version 3.5 (for AjaxControlToolkit 3.5). Due to the way IIS is structured, it would inherit the parent's web.config file, causing all sorts of problems and errors because the application would be finding TWO versions of system.web.extensions. This issue was not solved and we had to host the webapp under a new subdomain.

This problem could of been avoided, if we had just used jQuery, since it is completely decoupled from IIS.

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